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PREFACE 


The  need  for  a  centralized  data  base  and  data  manage¬ 
ment  system  has  long  been  recognized  by  the  medical 
community  as  essential  for  efficient  operation  in  the  face 
of  an  ever  increasing  patient  needs  and  treatments  and  the 
associated  administrative  load.  Until  the  completion  of 
this  thesis,  Wright-Patterson  Air  Force  Base  -  Medical  Cen¬ 
ter  (WPAFB-MC)  had  been  unable  to  begin  the  groundwork  for  a 
solution  to  their  information  management  needs  because  of 
other  problems  associated  with  completely  modernizing  the 
Medical  Center's  data  automation  program. 

To  initiate  a  project  of  this  magnitude  to  completion 
and  at  the  same  time  produce  results  which  are  accurate, 
useful  and  meaningful  to  WPAFB-MC  required  the  combined 
efforts  of  many  people.  Grateful  appreciation  is  extended 
to  the  WPAFB-MC  Data  Processing  Department  and  the  heads  of 
all  the  hospital  directorates  and  divisions  who  willingly 
and  supportlvely  participated  in  the  data  analysis  inter¬ 
views  . 

Heartfelt  thanks  is  given  to  my  thesis  advisor 
Dr.  Henry  Pot.oczn.v  and  to  committee  member  Ma,1 .  Chuck  Lillie 
who  provided  tremendous  moral  support,  innumeralbe  impartial 
evaluations  and  recommendations  and  managed  to  keep  me  on 
track. 


Special  gratitude  is  extended  to  two  people  who. 


without  their  help,  this  project  Drobably  could  not  have 
been  completed  on  time.  Maj.  C.  Modliszewski  and  Mr. 
Raymond  E.  Girard  spent  many  hours  helping  me  understand 
the  data  needs  of  WPAFB-MC. 

Finally,  I  owe  a  measureless  debt  to  my  wife,  Kathleen, 
and  daughter,  Stacy,  without  whose  support,  encouragement 
and  understanding  on  the  home  front  1  would  have  never 
completed  the  paper  presented. 
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ABSTRACT 


V.j. 

'A  partial  centralized  relational  data  base  in  third 
normal  form  was  designed  for  use  by  the  staff  of  the  United 
States  Medical  Center  Wright-Patterson .  Information 
requirements  were  gathered  by  means  of  an  in-depth 
data/information  analysis  at  the  directorate  and  division 
level,  and  used  as  the  basis  of  the  design.  Provided  with 
the  design  is  a  detailed  data  dictionary  and  an 
implementation  plan. 

As  a  result  of  certain  facts  gathered  during  the 
data/information  analysis,  several  management  and 
organizational  recommendations  were  made  to  the  Medical 
Center.  The  aim  of  these  recommendations  was  to  make  the 
implementation  and  management  of  the  data  base  easier, 
cheaper  and  responsive  to  the  users. 


ix 


I.  INTRODUCTION 


OBJECTIVES 

The  intent  of  this  thesis  is  to  develop  a  detailed 
method  for  specifying,  implementing,  and  demonstrating  a 
conceptual  model  of  the  administrative  portion  of  Wright 
Patterson  AFB  -  Medical  Center  (WPAFB-MC).  The  schema  has 
been  developed  in  a  style  that  can  be  generalized  to  other 
areas  of  the  hospital  so  as  to  cultivate  a  Hospital  Infor¬ 
mation  System  (HIS).  If  such  a  process  is  pursued,  it  is 
advisable  to  incorporate  the  administrative  module  presented 
in  this  paper  as  the  basic  step. 

The  areas  examined  in  the  hospital  for  this  report  are: 
Patient  Affairs,  Plant  Management,  Resource  Management, 
Administrative  Office,  Directorate  of  Hospital  Services  and 
Department  of  Nursing.  These  areas  were  selected  because 
of  commonality  of  data  and  relative  stability  of  information 
flow.  It  is  hypothesised  that  through  careful  analysis  of 
these  data  elements  and  their  flow,  insight  can  be  gained  in 
the  issues  that  pertain  to  the  development  of  a  Data  Base 
Management  System  (DBMS).  The  issues  refered  to  are: 

-  The  information  system  requirements  of  WPAFB-MC 

-  The  development  of  a  Data  System  for  improving 
the  efficiency  of  the  hospital 

-  Cost  benefits  of  such  a  system 

-  Type  of  DBMS  that  will  work  on  existing 
hardware 


BACKGROUND 


In  the  last  few  years,  the  application  possibilities  for 
data  processing  in  the  hospital  environment  has  considerably 
increased  owing  to  the  advent  of  the  computer.  Recognizing 
this  need  the  Department  of  Defense  (DOD)  purchased  hardware 
along  with  proprietary  software  to  aid  the  military  hospi¬ 
tals  in  meeting  their  information  support  needs.  This  pro¬ 
vision  of  support  is  no  small  undertaking  when  one  reviews 
the  tasks  defined  by  APR  169-6  for  a  medical  center. 

An  area  medical  center  is  a  large  hospital 
designated  by  the  Surgeon  General,  USAF,  and 
staffed  and  equipped  to  provide: 

(1)  Medical  and  dental  care  for  authorized 
personnel . 

(2)  The  widest  range  of  specialized  and  con¬ 
sultative  support  for  all  Medical  Treatment  Facili¬ 
ties  within  the  area,  as  outlined  in  the  consoli¬ 
dated  mission  statements  for  area  medical  centers 
published  by  HQ  USAF/SGHM. 

(3)  Postgraduate  education  in  health 
professions . 

(4)  Physical  evaluation  board  referral 
service.  An  area  medical  center  is  the  primary 
Air  Force  hospital  in  its  area.  It  performs  three 
principal  functions  -  patient  service,  education, 
and  research.  In  the  first  function,  the 
experience  of  its  staff  and  the  variety  of  its 
supporting  equipment  and  other  resources  provide  a 
capability  for  definitive  care  to  patients 
referred  by  smaller  facilities  in  the  area, 
patients  from  other  area  medical  centers,  and 
paitients  regulated  from  worldwide  sources  by  the 
Armed  services  medical  regulating  office  (ASMRO). 

In  the  second  function,  it  conducts  an  extensive 
education  program  in  health  care  sciences  and  a 
consultant  program  for  regional  hospitals.  In  the 
third  funciton,  it  carries  out  health  research 
projects  necessary  to  support  the  education 
program. 


However,  the  provided  software  could  not  handle  the 
tasks  set  forth  for  a  medical  center.  It  merely  became  a 
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collection  of  inflexible  routines.  This  condition  lasted 
until  October  of  1977  when  a  assemblage  of  operational  and 
strategic  computer  groups  met  and  developed  new  software 
and  software  policies  that  would  be  more  responsive  .to  the 
needs  of  the  medical  information  environment.  This  improve¬ 
ment  was  confirmed  by  unofficial  records  to  have  increased 
functional  users  by  thirty  per  cent. 

But  despite  the  changes  the  use  of  the  computers  is 
still  limited  to  specialized  report  routines  that  are  unique 
to  the  owning  office.  In  some  cases  the  transition  from 
manual  record  keeping  to  automated  record  keeping  has  never 
occurred.  As  a  result  massive  duplication  of  data,  data 
types,  and  human  effort  are  continually  occurring.  This 
translates  to  less  than  optimum  use  of  resources  and  thus 
waste  in  manpower  and  dollars. 

To  relieve  this  thriftless  condition  a  single  integrated 
data  base  must  be  planned  and  implemented.  It  must  be 
specifically  designed  for  modular  implementation  so  as  to 
eventually  support  a  total  HIS. 

PRESENT  SYSTEM 

As  was  stated  in  the  BACKGROUND  section  the  computer 
system  that  exists  at  WPAFB-MC  has  undergone  some  changes 
(for  the  better)  ever  the  past  few  years.  In  fact  the 
system(s)  that  exist  today  provide  many  enhancements  and 
cost  savings  to  the  military  that  would  not  have  been  possi- 


ble  otherwise.  Some  of  these  positive  aspects  are: 

1)  Word  processing  capability  that  reduces  through¬ 
put  times  of  reports  and  correspondence  by 
approximately  forty  percent. 

2)  Increased  awareness  of  manhour  savings  realized 
through  the  use  of  electronic  transfer  of  data. 

3)  Intrinsic  administrative  off-shoots  such  as  sta¬ 
tistical  inputs. 

)  User  defined  formatting. 

5)  Improved  discipline  for  dynamic  standardization 
of  data. 

Even  with  these  gains  in  information  capability  the 
demands  on  the  computer  center  keep  increasing.  This  is 
propagated  by  the  attitude  that  the  computer  is  the  answer 
to  hospital  work  areas  that  are  pressured  by  increasing  work 
loads  while  being  required  to  operate  under  constraints  of 
cost  and  manpower  budgets.  These  loads  are  generally  in  the 
form  of  increase  reporting  regulations,  administrative  de¬ 
mands  for  increased  productivity  and  reporting,  and/or  im¬ 
proved  services.  (Ref  20,  P  21) 


Because  of  these  demands  the  productivity  and  caliber  of 
work  developed  in  the  center  is  being  prematurely  taxed  to 
its  limits.  This  in  part  is  due  to  the  practice  in  the 
Department  of  Defense  Tri-Service  Medical  Information  Sys¬ 
tems  Agency  (TRIMIS)  of  procuring  stand  alone  systems  that 
retain  for  the  vendor  all  his  proprietary  rights. 


An  approach  often  used  involved  the  selection  and 
purchase  of  stand-alone  systems  which  apply  to 
specific  functional  areas.  There  are  numerous 
systems  available  to  aid  hospital  management  in  the 
so-called  business  aspects  of  the  health  care 
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institution.  These  systems  generally  contain 
applications  software  dealing  with  patient 
accounting,  general  ledger/responsiblillty 
reporting,  cost  allocation  (for  cost  accounting 
purposes),  inventory  reporting,  property  ledger, 
accounts  payable,  personnel  records,  accounts 
receivalble  functions,  and  payroll  functions. 
Other  stand-alone  systems  generally  procured  by 
hospitals  include  clinical  laboratory  systems, 
patient  monitoring  systems,  automated  medical 
history  taking  systems,  EKG  analysis  packages, 
patient  appointment  systems,  and  other  highly 
specialized  sub-systems  packages  to  meet  specific 
functional  requirements  within  a  hospital.  The 
Individual  hospital  generally  has  no  opportunity  to 
change  programs  or  modify  procedures.  (13-16) 


This  is  not  a  unique  practice  for  medical  institutions  as 
reported  by  Barnett  and  Zielstorff.  "...  Its  primary  pur¬ 
pose  is  an  ancillary  area  support  system,  which  Is  aimed  at 
improving  the  information-related  activities  of  individual 
service  units  such  as  the  pharmacy,  the  clinical  laborator¬ 
ies,  the  radiology  department,  or  the  admitting  office"  (Ref 
l»,  p  157).  A  second  type  of  system  employed  at  the  WPAFB-MC 
Is  a  transactional  system,  which  is  "primarily  concerned 
with  financial  management  and  concentrates  on  recording  the 
use  of  services  or  goods  for  the  purpose  of  billing"  (Ref 
P  157). 


Inherent  in  this  approach  to  data  processing  is  the 
hierarchial  summarization  of  the  world.  Such  a  methodology 
Is  not  only  wasteful  in  terms  of  memory  and  logically  ques¬ 
tionable,  but  also  quarantees  data  inconsistency  (Ref  13,  p 
32).  These  inconsistencies  are  in  part  due  to  the  duplica¬ 
tion  of  data  in  specific  files  that  are  structured  to  par¬ 
ticular  applications.  Thus  when  updates  are  made  a  lack  of 


agreement  in  data  entries  begins  to  occur  because  it  applies 
only  to  one  specific  file  rather  then  all  files  containing 
that  data  item. 

These  problems  of  questionable  logic,  data  inconsisten¬ 
cy,  duplication  of  data,  and  the  inability  of  the  user 
community  to  treat  the  existing  data  as  a  general  resource 
all  of  the  time,  keeps  the  users  from  interfacing  with  the 
data.  Thus  an  inward  spiral  is  established  which  will 
prematurely  limit  the  data  processing  function  to  concen¬ 
trate  on  data  processing  rather  than  on  service  delivery. 
(Ref  8,  p  3) 

It  is  the  issue  of  service  and  the  need  to  satisfy  user 
needs  and  functions  in  the  organizational  environment  which 
are  the  true  context  for  a  data  base  management  system.  (Ref 

8,  p  1*1 ) 

By  establishing  a  hospital  DBMS  the  flexibility  a  Hos¬ 
pital  Information  System  requires  will  be  permitted.  Thus, 
problems  previously  elicited  will  be  significantly  reduced, 
if  not  eliminated. 

GENERAL  GOALS  SYSTEM  WILL  MEET 

Data  bases  have  many  straight  forward  benefits  that  have 
an  immediate  appeal:  the  ability  to  share  data,  reduce 
redundancy,  and  eliminate  Inconsistency,  are  some  of  the 
obvious. (Ref  13)  These  benefits  follow  from  the  fact  that 
there  is  a  need  to  store  data  only  once.  It  was  a  review  of 


these  benefits  that  formed  the  basis  of  the  general  goals 
and  requirements  that  the  ultimate  HIS  will  meet.  A  listing 
of  these  goals  are: 


1.  Consistency  and  non-redundancy 

The  information  should  be  organized  to  minimize 
complications  arrising  from  needless  repetitions  and  lack  of 
agreement. 

2.  User-oriented 

The  system  should  be  oriented  to  medical  and 
administrative  professionals.  It  must  be  natural  and  simple 
for  the  user  to  submit  requests  for  information. 

3.  Efficiency 

Due  to  frequent  changes  in  patient  condition,  personnel, 
and  logistic  support  Information  may  become  obsolete 
rapidly.  The  value  of  information  depends  on  timeliness. 
Efficient  storage,  retrieval  and  manipulation  schemes  are 
required . 

4.  Standardization 

Because  HIS’s  are  complex,  the  cost  of  development  and 
maintenance  is  high  and  can  be  Justified  only  with  a  large 
volume  of  data.  Standardization  of  information  format  would 
allow  sharing  and  merging  of  systems  within  and  among 
hospitals. 

5.  Modularity 

It  is  desirable  that  the  system  be  modular  so  that  it 
can  be  tailored  to  meet  the  different  requirements  of 
individual  hospitals. 

6.  Reliability 

Hospitals  are  operational  twenty-four  hours  a  day  and 
computer  system  availability  must  be  maximized.  Recover 
capability  must  be  provided  so  brief  failure  will  not  reduce 
the  quality  of  work  within  the  hospital. 


It  is  essential  that  any  information  design  of  a  DBMS  in 
support  of  a  Hospital  Information  System  be  carried  out  with 
consideration  of  the  above  factors. 


OVERVIEW  -  A  CONCEPTUAL  FRAMEWORK 


Experience  and  research  have  shown  that  in  any  develop 
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ment  process  for  information  systems  it  is  important  to 
identify  clearly  the  potential  users  of  the  information  and 
the  uses  to  which  it  will  be  put.  This  is  a  fundamental 
step  that  is  often  ignored.  This  oversight  often  gives 
misleading  results  which  end  in  a  discrediting  of  the  entire 
computer  operation.  To  avoid  such  a  blunder  in  this  project 
this  thesis  will  rely  on  a  break  down  of  information  pro¬ 
posed  by  a  prominent  authority  in  the  field  of  management 
science,  Robert  Anthony.  His  position  is  that  there  are 
several  distinct  classes  of  information  required  for  any 
organization:  strategic  planning,  management  control,  and 
operational  control. 

A.  STRATEGIC  PLANNING 

Strategic  planning  is  the  process  of  deciding  on  objec¬ 
tive  of  the  organization,  on  changes  in  these  objectives,  on 
the  resources  needed  to  attain  these  objectives,  and  on  the 
policies  that  are  to  govern  the  acquisition,  use,  and  dispo¬ 
sition  of  those  resources. 

With  reference  to  WPAFB-MC,  strategic  planning  activ¬ 
ities  include  decisions  on  program  objectives,  service  fa¬ 
cility  locations,  target  population  definitions,  long-range 
budgeting  and  fore  casting,  resource  allocation  decisions 
and  policy  options.  This  type  of  planning  is  dependent  on 
external  sources  such  as  demographic  studies,  estimates  of 
costs  and  other  factors  involved  in  feasibility  studies. 
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B.  MANAGEMENT  CONTROL 

Anthony  suggests  that  management  control  is  the  process 
by  which  managers  assure  that  resources  are  obtained  and 
used  effectively  in  the  accomplishment  of  the  organization's 
objectives.  This  definition  is  intended  to  convey  three  key 
ideas.  First,  the  process  involves  managers,  people  who  get 
things  done  by  working  with  other  people.  Second,  the 
process  takes  place  within  a  context  of  objectives  and 
policies  that  have  been  determined  in  the  strategic  planning 
process.  Third,  the  criteria  relevant  for  Judging  the  ac¬ 
tions  taken  in  this  process  are  effectiveness  and  efficien¬ 
cy.  With  reference  to  WPAFB-MC  management  control  activi¬ 
ties  include  the  determining  of  staffing  and  capacity  re¬ 
quirements,  performance  monitoring,  target-setting,  short¬ 
term  budgeting,  and  the  training  of  new  personnel  to  meet 
standards  of  quality  in  performance. 

As  opposed  to  information  used  in  the  strategic  planning 
process,  a  management  control  system  may  be  usefully  con¬ 
ceived  based  primarily  on  internal  operating  data.  An  exam¬ 
ple  of  a  Statistical  DBMS  used  for  management  control 
purposes  is  a  utilization  system.  Such  a  system  would 
encounter  records  of  patient  visits  to  tabulate  utilization 
of  provider  personnel  and  medical  technology.  The  informa¬ 
tion  would  then  be  used  to  make  adjustments  in  staffing  and 
equipment  requirements. 
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C.  OPERATIONAL  CONTROL 

Mr.  Anthony  describes  the  third  class  of  activities 
within  an  organization  as  operational  control,  that  is,  the 
process  of  assuring  that  specific  tasks  are  carried  out 
effectively  and  efficiently.  As  the  definition  suggests, 
the  focus  of  operation  control  is  on  individual  tasks  or 
transactions;  scheduling  and  controlling  individual  jobs  as 
contrasted  with  measuring  the  performance;  procuring  speci¬ 
fic  items  for  inventory  as  contrasted  with  the  management  of 
inventory  as  a  whole;  specific  personnel  actions  as  con¬ 
trasted  with  personnel  management,  etc.  An  example  of  the 
operational  control  activities  at  WPAFB-MC  would  include 
scheduling  of  visits,  inventory  control,  patient  record 
maintenance,  accounting  systems,  and  staff  scheduling. 

This  report  will  deal  primarily  with  development  for  the 
operational  control  area.  One  reason  for  this  is  that 
operational  control  decisions  are  programmable  in  the  sense 
that  decision  rules  can  be  specified  which  produce  an  opti¬ 
mum  relationship  of  resource  inputs  (e.g.,  WPAFB-MC  person¬ 
nel,  administrative  tasks)  to  outputs  (e.g.,  patient  care). 
(Ref  1) 
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II.  THE  COLLECTION  PROCESS 


OVERVIEW 

When  one  sets  out  to  design  a  data  base  that  will  be 
implemented  into  a  DBMS,  it  seems  like,  at  first  blush,  a 
moderate  undertaking.  All  one  has  to  do  is  develop  rela¬ 
tions  and  normalize  them  to  at  least  third  normal  form  (3NF) 
so  as  to  insure  that  insert,  update  and  delete  anomalies  do 
not  occur.  (If  the  terms  3NF,  normalize,  relations,  etc.  are 
not  familiar  to  the  reader  please  refer  to  glossary  in  the 
appendix.)  The  next  obvious  step  is  to  choose  a  DBMS  that 
will  support  the  relations  developed.  But  this  is  not  all 
that  is  involved  in  the  data  base  development  process.  It 
is  merely  the  tip  of  the  data  iceburg.  The  part  of  the 
process  that  is  not  apparent  and  needed  to  crack  the  data 
iceburg  is  the  methodology  used  tr  ascertain  what  data 
exists  in  the  iceburg  or  in  a  more  familiar  term  the  organi¬ 
zation.  The  method  employed  should,  at  some  pre-set  stop¬ 
ping  point,  be  able  to  identify  data  elements  and  the  rela¬ 
tions  they  compose.  It  should  also  identify  the  information 
connectors  that  model  the  flow  of  information  throughout 
the  organization  under  investigation.  It  will  also  demon¬ 
strate  inter  and  intra  information  flow  of  functional  areas 
that  comprise  the  organization  and  of  functional  areas  them¬ 
selves  . 

PRIMAL  PHASE 

To  begin  such  a  process  it  is  necessary  to  gain  some 
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idea  of  the  dimension  that  the  data  the  organization  (under 
review)  generates  and  uses.  In  the  case  of  WPAFB-MC  this 
required  face  to  face  interviews  with  the  head  of  the  Medi¬ 
cal  Information  System,  the  Associate  Medical  Center  Admin¬ 
istrator  and  the  Medical  Center  Administrator.  This  meeting 
established  that  the  implementation  of  a  DBMS  would  be 
beneficial  to  the  WPAFB-MC  and  should  be  undertaken.  This 
is  the  inaugural  step. 

But  despite  vicinal  backing  there  is  one  other  area  of 
concern  that  must  be  evaluated  and  that  is  the  present  and 
future  programs  of  the  Department  of  Defense.  This  level 
must  be  evaluated  and  coordinated  with  to  ensure  that  any 
local  design  can  be  done  in  concert  with  their  efforts. 

As  covered  in  Chapter  1  the  DOD  agency  governing  WPAFB- 
MC  is  the  TRIMIS  office.  It  was  determined  that  some  inputs 
from  their  agency  would  be  of  use  in  developing  information 
flow  patterns.  Unfortunately  it  was  felt  that  their  ideas  on 
DBMS’s  were  limited  and  relied  too  heavily  on  their  subcon¬ 
tracted  consultant  firm  ’’Libra  Technology".  This  is  typical 
of  most  bureaucratic  institutions  be  they  civilian  or  mili¬ 
tary. 


The  final  part  of  the  primal  phase  involved  casual 
discussions  with  the  potential  users  who  are  intended  to  be 
incorporated  into  the  data  base.  Since  this  is  the  first 
contact  the  data  base  designer  has  with  future  users  it  is 
essential  that  the  discussion  be  limited  to  an  overview  of 
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what  a  DBMS  is  and  the  potential  use  it  has  to  them.  The 
key  is  to  create  an  interest  on  the  part  of  the  user.  So, 
it  is  advisable  to  limit  terminology  to  a  vernacular  that 
computer  illiterates  can  visualize  physically.  The  example 
used  in  this  study  involved  a  file  cabinet.  The  cabinet  was 
referenced  as  the  computer.  The  file  folders  inside  were 
described  as  the  file  structure/relations  that  either  cur¬ 
rently  exist  or  would  be  defined.  The  documents  inside  the 
folders  were  described  as  the  data  elements/attributes. 
And,  the  process  of  interaction  with  the  files/relations  in 
the  cabinet/computer  to  extract  viable  information  was  de¬ 
picted  as  what  the  DBMS  would  do  if  designed  properly.  The 
entire  encounter  should  be  limited  to  a  time  span  of  fifteen 
to  twenty  minutes. 

CANVAS  PHASE 

Since  the  initial  contact  with  the  users  can  be  com¬ 
pleted  in  one  to  two  days  there  is  little  loss  in  momentum 
in  gaining  insight  into  the  information  flow  of  the  hos¬ 
pital.  Thus  after  all  designated  functional  areas  have  been 
contacted  it  is  necessary  to  develop  an  appointment  sequence 
which  will  allow  checks  on  information  provided  by  the 
functional  areas.  The  process  used  in  this  paper  relied  on 
contacting  department  supervisors  and  asking  two  general 
questions  -  "Tell  me  in  simple  terms  what  your  office  does 
that  contributes  to  the  hospital  being  able  to  meet  its 
mission  goal?"  and  "Of  the  subunits  that  make-up  your  func¬ 
tional  area  give  me  a  brief  description  of  the  impact  if  it. 
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the  sub-area,  no  longer  exists?”  .  These  questions  will 
help  to  identify  jobs  that  deal  solely  with  planning  or 
controlling  and  thus  save  time  since  these  are  areas  that  do 
not  belong  in  this  data  base  management  system. 

DATA  COLLECTION  METHODS 

The  following  paragraphs  will  illustrate  the  data  col¬ 
lection  techniques  used  in  the  development  of  the  proposed 
DBMS.  The  examples  presented  deal  with  data  collection  in 
clinics,  plant  management,  wards,  etc.  The  methods  employed 
are  not  limited  to  the  examples  shown  but  only  demonstrate 
the  techniques  that  should  be  applied  in  a  data  collection 
throughout  the  hospital.  These  methods  were  applied  with 
minor  adjustments  in  all  of  the  functional  areas  outlined  in 
Chapter  1.  As  an  added  note  the  methods  demonstrated  can 
apply  to  any  Military  Treatment  Facility  (MTF)  with  consid¬ 
eration  given  to  the  individual  capabilities  of  the  MTF  and 
the  function  of  that  medical  facility.  Additional  con¬ 
straints  such  as  time  and  money  will  also  dictate  altera¬ 
tions  in  the  methods  presented. 

INTERVIEWS 

Interviews  were  structured  with  questions  such  as  the 
following: 

-  What  records  or  logs  are  used  to  record 
patient  appointments? 

-  Are  separate  statistics  collected  for  dif¬ 
ferent  characteristics  of  patient  ap¬ 
pointments,  e.g.,  number  of  walk-ins, 
number  of  priority  changes,  etc.  ? 


What  time  frame  is  employed  to  record  these 
transactions  ?  Hourly  ?  Shift  ?  Daily  ? 
Weekly  ?  Monthly  ?  Yearly  ? 

How  does  your  work  area  access  these  rec¬ 
ords  ? 

Are  manual  logs  kept  to  back  up  computer 
failures  ? 

What  is  the  average  workload  for  the  clin¬ 
ic  ? 

What  interactions  exist  between  the  clinic 
and  the  Pharmacy?  Clinic  and  the 
Laboratory?  Clinic  and  Records  ? 

What  information  requests  are  received  from 
other  areas,  i.e.,  resource  management  ? 
How  many  and  from  what  areas  ? 

How  is  area  data  recorded,  i.e.,  by  number 
of  patients,  type  of  affliction  or  by 
active  duty/  dependent? 

What  are  the  clinics  peak  seasons,  time  of 
day,  days  of  week,  etc.  ? 

What  data  management  problems  are  encounter- 
tered  by  the  clinics  as  a  whole  ? 


The  answers  to  these  and  other  questions,  as  determined 
by  type  of  functional  area,  enabled  identification  of  func¬ 
tional  boundaries  as  well  as  relationships  that  existed 
between  the  functional  boundaries  and  within  the  boundaries. 
This  enabled  the  start  of  a  model  to  depict  the  information 
flow. 

INFORMATION  FLOW  DIAGRAM 

Having  developed  the  genre  of  questions  necessary  for 
discovering  the  data  elements  and  their  information  uses,  it 
was  necessary  to  build  a  general  model  that  depicted  in  a 
graphic  form  the  functional  connections  of  the  hospital. 
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This  was  done  prior  to  any  in  depth  interviews.  The  rea¬ 
soning  for  this  approach  was  that  a  quiding  model  graphic 
could  aid  the  Interviewer  as  well  as  the  interviewees  in 


constructing  concise  descriptions  of  how  their  specific 
areas  functioned  within  the  MTP.  Figure  II-l  is  the  mor  ?1 
that  was  finally  used  in  the  interviews.  The  diagram  was 
developed  from  information  Drovided  by  the  "Process  Con¬ 
dition  -  Action  Diagram  Flowcharts"  of  Walter  Reed  Army  Med¬ 
ical  Center  Study  published  in  1976.  Thus  what  follows  are 
the  condensed  accounts  of  what  was  revealed  by  interviews 
concerning  function  and  information  flow  within  and  between 
Patient  Affairs,  Plant  Management,  Resource  Management, 
Administrative  Office,  Directorate  of  Hospital  Services  and 
Department  of  Nursing. 

A.  Patient  Affairs 

The  Patient  Affairs  office  is  primarily  concerned  with 
matters  that  deal  with  monitoring  patient  use  of  medical 
facilities.  The  areas  addressed  in  this  study  were:  Air 

Evac,  Champus  and  Administrative  Support. 

1.  The  Air  Evac  system  involves  identifying  patients  that 
need  to  be  transported  from  one  MTF  to  another  due  to 
the  non-availability  of  medical  specialties  at  their 
base  of  origin.  This  process  is  not  a  simple  one. 
Further  questions  revealed  that  there  were  restrictions 
on  who  could  use  this  system.  The  potential  user  had 
to  be  on  active  duty  or  retired  from  one  of  the 
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Figure  II-l.  Information  Flow  Diagram 


branches  of  the  service,  a  dependent  or  in  very  special 
cases  a  member  of  the  civilian  community  (e.g.  severe 
burn  case  from  a  civilian  air  crash  would  be  moved  via 
military  air  evac  if  civilian  transport  was  not  avail¬ 
able).  Once  the  potential  user  is  identified  as  quali¬ 
fied  for  an  air  evac  he/she  must  be  admitted  into  the 
hospital  and  scheduled  for  movement.  This  causes  de¬ 
mands  on  staff,  equipment  and  facilities. 

To  give  the  reader  a  clearer  understanding  of  how  the 
Air  Evac  system  impacts  other  areas  of  the  hospital  the 
following  example  is  provided. 


An  enlisted  Air  Force  person  stationed  at 
WPAFB-MC,  Oh.,  is  diagnosed  as  having  disease 
X.  It  is  well  known  that  proper  treatment 
for  such  an  illness  can  be  best  supported  at 
Wilford  Hall,  Lackland  AFB,  Texas.  The  proce¬ 
dure  for  moving  this  patient  via  airplane  is 
chosen  due  to  the  severity  of  the  disease. 
So,  the  patient  is  admitted  to  the  local  mili¬ 
tary  hospital.  This  required  admission  forms 
and  assignment  of  a  bed  In  a  specific  ward. 
This  in  turn  affects  personnel  scheduling 
(e.g.  physicians,  nurses,  technicians,  etc.) 
and  consumption  of  hospital  supplies  (drugs, 
dietary,  linens,  etc.) 


2 .  CIVILIAN  HEALTH  and  MENTAL  PROGRAM  of  the  UNIFORMED 
SERVICES  (CHAMPUS) 

The  CHAMPUS  office  within  WPAFB-MC  advises  patients  and 
staff  in  matters  involving  CHAMPUS.  The  office  assists 
sponsors  in  applying  for  benefits  administered  under 
CHAMPUS,  as  well  as  advising  sponsors  of  available  services 
within  the  MTF.  An  additional  function  is  providing  sup¬ 
plemental  authorizations  for  medical  care  in  the  local 
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community  due  to  non-availability  at  the  military  institu¬ 
tion.  An  example  of  this  would  be  special  diagnostic  tests 
or  consultant  examinations.  The  rest  of  the  functions  in¬ 
volve  agencies  and  data  that  are  external  to  the  hospital 
information  flow,  therefor,  they  are  not  included  in  this 
discussion.  An  example  of  how  this  process  is  employed 
follows . 


Colonel  Myers,  neurosurgeon,  has  noted  symp¬ 
toms  of  bradicardla  in  a  six  month  old  female. 
The  symtoms  suggest  pressure  is  occurring  in 
the  posterior  fossa  region  of  the  scull. 
However,  the  CAT  scanner  at  WPAFB-MC  can  not 
give  clear  resolution  of  that  region  of  the 
brain.  Therefor  he  has  requested  that  an  EMI 
scanner  be  used  to  confirm  diagnosis  of  cere¬ 
bral  fluid  pressure  before  attempting  surgery. 
In  addition  he  is  requesting  a  consult  from  a 
civilian  neurosurgeon  who  is  familiar  with 
these  special  test  procedures.  To  accomplish 
these  requests  the  CHAMPUS  office  must  coordi¬ 
nate  supplemental  funding. 


3.  ADMINISTRATIVE  SUPPORT 

This  area  supervises  the  administrative  functions  of 
admission,  disposition  and  transfer  of  patients.  This  in 
turn  involves  the  administrative  control  of  patients  and 
beds.  It  assigns  patients  to  inpatient  units,  arranges  for 
receiving  and  safeguarding  patient  valuables  (baggage  and 
clothing),  and  initiates  preparation  of  individual  inpatient 
and  related  administrative  records. 


The  Administrative  Support  Area  compiles  data  and 
prepares  recurring  and  special  reports  pertinent  to  admis¬ 
sion,  classification  and  disposition  of  patients.  It  en- 


II-9 


sures  that  vital  statistic  data  are  properly  documented.  It 
receives  and  monitors  recurring  statistical  reports  of  hos¬ 
pital  services.  It  also  ensures  that  the  data  compiled  is 
made  known  to  the  administrative  and  professional  staffs. 

Advising  the  appropriate  Civilian  Base  Personnel  Office 
(CBPO),  in  as  prompt  a  fashion  as  possible,  is  the  Adminis¬ 
trative  Support  Areas  responsibility  when  a  patient  member 
is  expected  to  be  hospitalized  in  excess  of  ninty  (90)  days. 
If  third  party  liability  notification  is  necessary  this 
office  is  responsible. 

This  area  provides  administrative  support  for  Medical 
Evaluation  Boards  (MEB),  Physical  Evaluation  Boards  (PEB) 
and  examination  of  members  on  the  temporary  retired  list 
(TDRL) . 

The  Administrative  Support  Area  reviews  and  processes 
health  records.  If  records  are  not  complete  they  are  iden¬ 
tified  and  referred  to  the  responsible  provider,  or  depart¬ 
ment  supervisor  for  correction.  It  compiles  clinical  record 
statistical  data  and  prepares  reports  based  thereon.  It 
also  maintains  inpatient  record  files.  Lastly,  it  provides 
required  information  to  the  health  record  committee  and  the 
medical  care  evaluation  committee. 

B.  PLANT  MANAGEMENT 

The  principle  purpose  of  plant  management  is  to  provide 
a  clean,  safe  and  adequate  environment  for  patient  care 
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within  the  hospital.  This  is  accomplished  through  a  compre¬ 
hensive  interior  and  exterior  facility  maintenance  program, 
fire  and  ground  safety  programs,  ground  maintenance,  securi¬ 
ty,  housekeeping,  work  order  control  and  programming  activi¬ 
ty,  hospital  space  utilization  program  and  emergency  plan¬ 
ning  for  disasters.  From  the  functional  descriptions  pre¬ 
sented  it  was  concluded  that  the  majority  of  data  used  or 
shared  with  this  functional  area  would  be  relatively  static 
and  should  be  included  in  relations  that  were  not  accessed 
for  updates  on  a  continuing  basis.  An  example  of  this 
concept  follows. 

John  Doe  is  about  to  be  admitted  to  the  hos¬ 
pital  and  the  following  information  is  needed: 

Is  there  a  phone  in  the  room? 

Has  the  room  been  cleaned? 

Is  there  a  bed  In  the  room? 

Can  the  room  be  secured? 

Are  linens  available  for  the  bed? 

Is  the  necessary  support  equipment  available  and  in 

good  working  condition  for  this  patient? 

The  answers  to  these  questions  plus  others  not  mentioned  all 
stem  from  the  plant  management  area  of  control.  The  data 
tends  to  become  part  of  the  background  noise  of  any  hospital 
but  is  essential  to  the  proper  care  and  well  being  of  the 
patient  both  mentally  and  physically. 

C .  RESOURCE  MANAGEMENT 

The  tasks  this  functional  area  performs  involve  con¬ 
trolling  the  budget,  manpower,  and  management  improvement 
functions  of  the  base  medical  service.  The  major  elements 


11-11 


of  these  activities  are:  financial  management  (budget,  ac¬ 
counting,  fiscal  analysis),  manpower  programs,  management 
analysis,  and  medical  service  accounts. 

1.  Financial  management  interacts  in  the  information 
flow  by  establishing  monetary  controls  on  the  con¬ 
sumption  of  hospital  services  and  goods.  The  values 
established  for  the  goods  and  services  are  used  to 
compile  fiscal  values  which  can  be  analysed  for 
future  long  and  short  term  bugetary  needs. 

2.  Manpower  Programs  serve  as  the  monitor  that  com¬ 
pares  the  reported  workload  factors  with  the  au¬ 
thorized  manning  standards  to  determine,  in  coor¬ 
dination  with  supervisors,  if  adequate  manpower 
resources  are  available  for  each  work  area.  There 
are  several  other  functional  areas  this  work  area 
performs  but  they  are  beyond  the  scope  of  this 
paper. 

3.  Management  Analysis  interacts  with  the  information 
flow  of  the  functional  areas  by  developing  metrics 
which  measure  work  output,  e.g.,  patient  to  bed 
ratio,  patient  to  provider  ratio,  bed  days  to  aver¬ 
age  bed  days,  etc.  The  measures  are  then  translated 
into  manhours,  material,  space,  and  the  like  to 
produce  a  measure  of  work.  These  data  are  then 
collected  periodically  into  various  management  sum¬ 
mary  reports.  The  reports*  generic  classifications 
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are:  workloads,  costs,  budget  status,  staffings, 
etc . 


The  following  example  is  provided  to  demonstrate  a  more 
vivid  picture  of  how  this  agency  translates  data  elements 
into  workable  information  within  the  MTF. 


SGT  Garcia  has  been  in  the  hospital  for  one 
week.  He  had  been  air  evaced  due  to  the 
nature  and  severity  of  the  burns  he  sustained 
in  an  aircraft  accident.  Because  his  condi¬ 
tion  was  non  disease  in  origin  he  was  classi¬ 
fied  as  a  casualty  admit.  During  his  stay  he 
had  to  have  a  heart/respiratory  monitor,  which 
was  rented  from  a  local  civilian  hospital. 
Because  he  could  not  take  fluids  orally  they 
were  administered  intravenously.  His  con¬ 
dition  was  so  quarded  that  additional  staff  (2 
nurses)  were  needed  because  there  was  not 
adequate  space  to  accomodate  his  case  in  in¬ 
tensive  care. 


The  biometrics  that  SGT  Garcia's  stay  generated  are: 
patient  and  casualty  census  count  for  week,  month,  quarter, 
year;  expense  equipment  account  reduced  for  rental  machine¬ 
ry;  and  medical  supplies  (Expense  Equipment  are  all  items  of 
medical  and  nonmedical  equipment  having  a  unit  prices  of 
less  than  $3,000).  Also  additional  nurses  were  transfered 
from  another  department  thus  generating  an  AF  Form  896 
Personnel  Loaned  and  Borrowed  by  Cost  Center.  The  saturation 
in  the  intensive  care  unit  prompted  a  need  for  a  manning 
increase  requirement  since  it  was  determined  that  it  was  not 
an  isolated  incident.  A  check  of  equipment  also  revealed 
that  heart/respiratory  equipment  owned  by  the  hospital  was 
at  one  hundred  per  cent  capacity,  thus  budgeting  was  noti- 
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fled  to  increase  the  next  fiscal  years  budget  to  accommodate 
the  purchase  of  addition  life  support  equipment.  These 
metrics  were  all  incorporated  into  various  reports  that  were 
used  to  adjust  budgeted  projects,  re-evaluate  manpower 
needs,  and  provide  development  of  plans  to  anticipate  the 
future  needs  of  the  hospital. 

D.  ADMINISTRATIVE  OFFICE 

This  office’s  basic  function  is  to  support  all  other 
areas  of  the  hospital  in  an  administrative  capacity.  The 
responsibilities  include  maintaining  the  regulations  li¬ 
brary,  and  reviewing  local  drafted  regulations  and  distrib¬ 
uting  personnel  rosters.  Also  they  control  public  affairs, 
tours,  travel  orders  preparation,  and  special  commander’s 
briefings.  These  types  of  functions  do  not  contribute  data 
into  the  information  flow  of  the  MTF  but  can  capitalize  from 
reports  that  are  compiled  from  the  information  flow.  There¬ 
for  no  direct  contributions  could  be  determined  from  this 
area  as  it  relates  to  the  development  of  a  hospital  data 
base. 

E.  DIRECTORATE  OF  HOSPITAL  SERVICES 

The  information  that  flows  through  this  area  of  the  MTF 
involves  staff  activities  and  those  functions  that  pertain 
to  patient  care  and  the  documentation  thereof.  A  listing  of 
the  areas  that  may  be  involved  are:  credentialing,  medical 
audits,  antibiotic  usage,  utilization  review,  surgical  case 
review,  medical  records  review,  pharmacy  and  therapeutics. 


blood  utilization  review,  morbidity-mortality  review,  etc. 
Since  the  scope  of  this  area  was  too  large  for  this  project 
emphasis  was  given  to  scheduling  rosters  for  the  Medical 
Officer  of  the  Day  (MOD),  physician  retention,  and  special 
skills  manning  of  the  hospital.  An  example  of  this  infor¬ 
mation  flow  is  provided. 


Dr.  Mengle  has  had  to  be  MOD  for  the  last 
three  weekends.  He  is  quite  upset  with  the 
way  his  free  time  is  not  being  considered. 
Since  he  has  only  a  few  months  left  on  his 
service  commitment  date  he  has  decided  to  look 
in  the  civilian  community  at  what  opportuni¬ 
ties  are  available  for  his  specialty  -  neuro¬ 
surgery.  In  addition  his  license  needs  to  be 
renewed  in  less  than  a  month. 


F.  DEPARTMENT  OF  NURSING 

This  department  is  responsible  for  the  managment  of 
nursing  services.  This  is  no  small  task  when  one  realizes 
that  this  service  supports  all  areas  involved  in  the  care 
and  treatment  of  patients.  Because  of  time  constraints  and 
the  change  over  of  personnel  the  only  areas  discussed  dealt 
with  manning  problems,  special  training  requirements,  and 
scheduling  of  technical  nursing  personnel  to  nursing  activi¬ 
ties  based  on  skill  asessment.  A  representative  sample  of 
how  these  activities  work  follows: 

Two  months  ago  Captain  X  had  his/her  refresher 
training  in  cardial-pulmonary  resusitation  and 
gained  his/her  certification  as  a  scrub  nurse. 
He/she  presently  has  an  outdated  Job  skill 
identifier  and  thus  is  working  in  the  pedia¬ 
tric  clinic. 
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WHY  INTERVIEW 


The  major  strength  discovered  about  the  interview  pro¬ 
cess  was  the  speed  with  which  one  could  collect  and  reduce 
required  data.  However,  the  benefit  of  speed  was  offset  by 
some  inaccuracy  due  to  the  inexperience  of  the  interviewer 
and  the  interviewing  techniques  employed.  In  fact  it  was 
discovered  late  in  the  collection  process  that  a  very  simple 
DBMS  example  enhanced  the  quality  of  the  data  gleaned  from 
interviews.  Another  hinderance  encountered  that  must  be 
planned  for  in  interviews  is  the  tight  schedules  which  all 
too  often  conflict  with  data  collection  efforts. 


To  demonstrate  how  one  recognises  a  relationship  and 
the  data  elements  that  it  may  contain,  the  following  excerpt 
from  an  interview  with  a  representative  of  Plant  Management 
is  presented: 


One  of  the  problems  I  face  in  plant  management 
is  lost  (keys)  and  the  cost  of  changing 
(locks)  for  the  : rooms:  in  the  hospital 
:wards:.  You  see  all  the  keys  are  numbered 
and  correspond  to  a  -lock  which  is  numbered-. 
We  -sign  out  the  keys  to  supervisors:-  and 
due  to  the  constant  change  of  personnel  some 
of  the  keys  get  lost  or  damaged  and  it  becomes 
a  laborious  record-keeping  task. 


An  inspection  of  the  above  response  reveals  not  only 
the  possible  relations  and  data  elements  but  also  the  gra¬ 
phic  technique  used  during  the  interview  to  facilitate 
organization  of  the  elements  revealed. 

From  the  excerpt  two  possible  relations  can  be  identi- 
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fled  -  WARD  and  SUPERVISOR  .  The  reason  they  are  Initially 
identified  as  relations  is  that  they  are  terms  which  ’’common 
sense"  says  are  composed  of  many  elements  or  discriptors. 
In  contrast  to  the  relations  are  the  data  elements  -  lock 
number,  key  number  and  room.  They  are  atomic  terms  which 
either  lend  description  to  or  lend  some  type  of  pertinent 
quality  to  a  relation. 

As  mentioned  previously  graphic  symbols  were  used  to 
identify  relations,  attributes  and  functions.  The  symbols 
and  their  meaning  are: 

1)  (  )  used  for  atomic  elements. 

2)  :  :  used  for  relations. 

3)  -  used  for  function. 

These  symbols  speeded  up  the  interview  process  since  they 
allowed  for  quick  recognition  of  terms.  This  facilitated 
the  restructuring  of  the  interview  to  specific  pieces  of 
data  that  the  functional  area  would  profit  in  using  as 
information . 

RECORDS 

Since  the  interview  process  may  induce  some  inac¬ 
curacies  in  the  Information  model,  it  was  supplemented  by  a 
record  analysis  method.  The  records  pertinent  to  the  study 
proved  to  be  readily  available  and  little  training  or 
special  skills  were  required  by  the  data  collector.  It  was 
found  that  the  existing  reports  used  within  the  hospital  had 
distinct  data  elements  that  could  be  easily  identified  and 


incorporated  into  the  relations  that  emerged  from  inter¬ 
views.  However,  it  is  necessary  to  point  out  that  this 
process  proved  to  be  the  most  time  consuming. 

METHOD  OF  DOCUMENTATION 

The  key  to  making  sure  that  the  relations  are  worth 
using  in  a  DBMS  is  the  data  audit  trail.  It  must  be  simple 
and  accurate.  It  must  clearly  define  which  functional  areas 
share  data.  The  following  format  is  thought  to  have  all  the 
qualities,  previously  mentioned,  necessary  to  document  for  a 
DBMS : 


:  FUNCTIONAL 
:  AREA 

RELATION 

DATA  ELEMENT 

DEFINITION  " 
OR 

FUNCTION 

~SKAHFT>~T 

BY 

:  PLANT  MGMNT 

ROOMS 

KEY# 

SEE  DATA 
DICTIONARY 

SUPER-  : 
VISOR  : 

Figure  II-2.  Documentation  Record 

The  result  of  this  process  was  twenty-five  relations 
with  over  one  hundred  and  fifty  data  elements.  It  must  be 
stressed  that  throughout  the  evolution  of  the  DBMS  inter¬ 
views  and  record  audits  must  be  and  were  confirmed  by  the 
users  involved  to  ensure  validity  of  the  final  product. 
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III.  DISTILLING  THE  DATA 


OVERVIEW 

This  chapter  deals  with  the  procedures  used  to  or¬ 
ganize  and  implement  the  information  presented  in  Chapter  2 
into  a  logical  design.  The  procedures  employed  are  not  new, 
but  are  an  adaptation  of  the  Business  Systems  Planning  (BSP) 
method . 

BSP  APPROACH 

The  BSP  method  originated  with  IBM  for  their  own  inter¬ 
nal  use,  but  due  to  customer  demand  was  released  as  a 
general  methodology.  "The  primal  purpose  of  BSP  is  to 
identify  the  information  necessary  to  run  the  organization. 
It  is  suggested  the  master  development  plan  Include  resource 
requirements,  but  the  principles  and  quidelines  of  the  meth¬ 
odology  are  directed  at  information  requirements.”  (Ref  5, 
p  157) 

BSP  is  basically  a  two  phase  approach.  The  first  phase 
develops  a  broad  understanding  and  it  identifies  what  infor¬ 
mation  currently  supports  the  organization.  This  in  turn  is 
decomposed  into  a  network  of  information  systems  required  to 
support  the  organization.  Once  the  network  is  defined  its 
subsystems  are  prioritized  to  facilitate  implementation. 
The  primary  means  used  to  reveal  the  data  is  the  interview. 
Throughout  this  phase  emphasis  is  given  to  the  functional 
processes  without  regard  for  the  organizational  structure. 
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This  approach  tends  to  prevent  a  narrow  view  of  the  data. 

Because  people  are  inclined  to  measure  per¬ 
formance  in  terms  of  past  experience,  they 
tend  to  collect  data  that  are  meaningful  in 
these  terms.  As  a  result  their  data  becomes 
personalized,  lose  meaning  to  others  and  lead 
to  a  narrow  view  of  the  enterprise.  (Ref  14, 

P  2-3) 

Chapter  2  portrays  this  process. 

The  objective  of  the  second  phase  is  to  develop  a 
design  that  implements  the  network  of  information  systems. 
From  this  approach  modules  can  be  constructed  which  will 
eventually  evolve  into  a  total  information  system  for  the 
organization.  This  is  accomplished  by  assessing  the  defi¬ 
ciencies  of  current  systems,  identifying  processes  and  users 
that  share  data  along  with  functional  access  privileges. 
(Ref  5,  P  157) 

PROCESSES 

In  the  previous  chapter  twenty  (20)  processes  were 
exhibited  in  Figure  II-l.  Their  purpose  at  that  point  in 
the  development  cycle  was  to  produce  a  model  of  the  informa¬ 
tion  flow  of  the  hospital.  But  this  is  not  the  only  use 
they  have.  By  associating  them  with  the  six  (6)  functional 
areas  studied  one  can  begin  to  get  at  the  relations  that 
will  support  a  relatonal  data  base  management  system.  To 
accomplish  this  linkage  a  matrix  is  used.  In  fact  this  is 
the  first  of  several  matrices  that  will  be  used  throughout 
the  relation  development  process.  The  reason  why  matrices 
are  used  is  because  they  provide  a  convenient  method  to 
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analyze  associations. 


Before  any  matrix  can  be  utilized  for  specified  char¬ 
acteristics  it  will  be  necessary  to  give  the  process  being 
examined  as  complete  a  description  as  possible.  (This  pro¬ 
cess  will  need  to  be  periodically  reviewed  throughout  the 
entire  project  to  ensure  the  validity  of  the  nomenclature.) 
The  processes  being  considered  along  with  their  decriptions 
are  listed  in  Table  III-l  located  on  the  next  page. 

The  information  to  be  gained  from  a  functional 
area/process  matrix  analysis  is  a  reduction  of  the  processes 
and  a  prioritization  of  the  pertinent  processes.  In  addi¬ 
tion  it  is  anticipated  that  a  grouping  of  processes  would 
emerge  that  could  be  networked  into  an  information  system 
that  would  support  the  functional  areas  analyzed  in  this 
paper.  Figure  III-l  is  this  matrix. 

Analysis  of  the  matrix  reveals  that  two  (2)  of  the 
functional  areas  Plant  Management  and  Administrative  Office 
would  not  be  major  contributors  to  the  information.  This  is 
apparent  from  the  lack  of  entries  in  the  matrix  for  these 
two  areas.  It  is  speculated  that  as  much  as  fifty-one  per 
cent  of  the  data  necessary  to  WPAFB-MC's  information  system 
can  be  identified.  This  figure  is  a  ratio  of  filled  squares 
verses  total  number  in  the  matrix.  Unfortunately  confirma¬ 
tion  of  this  assertion  will  only  come  when  the  total  system 
is  built.  This  matrix  also  reveals  commonality  of  involve¬ 
ment  and  some  idea  of  the  extent  of  involvement.  However  the 
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1.  ADMINISTRATIVE  INFORMATION:  information  that  is 
generated  by  the  internal  management  structure  to 
monitor  the  effectiveness  of  the  hospital  in 
meeting  its  defined  goals.  Some  of  the  data 
collected  is  forwarded  to  higher  headquarters. 

2.  ADMISSION  DETAIL:  register,  initiate  or  locate 

medical  records,  assign  assession  number,  transfer 
to  ward  or  clinic 

3.  CURRENT  ADMISSION  DETAIL:  specifics  that  relate  to 
current  circumstances  of  admission,  that  is,  type 
of  illness 

4.  EXPENDITURE:  goods,  services  or  funds  consumed  in 

the  operation  of  the  hospital  as  it  provides  care 
to  patients 

5.  HIGHER  HQTRS  STATISTICS:  data  directed  to  be  com¬ 

piled  for  comparison  purposes 

6.  INFORMATION:  any  inquiry  concerning  the  status  of 

a  patient 

7.  OPERATIONAL  REPORT  OF  DEPTARTMENT:  rates  of  con¬ 

sumption  of  supplies  or  utilization  of  personnel 

8.  ORDER  FOR  SERVICE:  medications,  special  diets, 
therapy,  patient  education,  etc. 

9.  ORDER  FOR  SPECIAL  TREATMENT/SERVICE:  priority  re¬ 

quests  for  medical  tests  and  procedures 

10.  OCCUPANCY:  physically  in  place  in  the  hospital  and 
utilizing  personnel  and  equipment 

11.  PATIENT  ACC0M0DAT0N  RATE:  a  set  of  predetermined 

fees  to  be  assessed  according  to  number  of  days  in 
hospital  and  type  of  patient  category 

12.  PATIENT  ACCOUNT:  a  means  for  tracking  cost  of 

hospital  care 

13.  PATIENT  IDENTIFICATION:  a  unique  way  to  identify 

patient,  patient  records,  tests,  procedures  and 
accounts.  Normally  is  a  social  security  number  + 
dependent  code. 


Table  III-l(a).  Process  Listing 
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14.  PATIENT  MEDICAL  HISTORY:  information  relating  to 

patient’s  health  status,  usually  obtained  by 
medical  personnel.  It  will  also  include  obser¬ 
vations,  physical  examinations,  consults,  and  etc. 

15.  PERSONNEL  ACCOUNTING  INFORMATION:  processing  and 

maintaining  individual  personnel  records  related  to 
professional  skills  and  payment  of  employees 

16.  RESEARCH  INFORMATION:  investigations  or  experimen¬ 
tation  aimed  at  validation  or  interpretation  with 
reference  to  the  nature,  diagnosis,  treatment  and 
course  of  diseases 

17.  RESULT  OF  MEDICAL  EXAMINATION:  feed  back  from 

tests  and  Interpretations  of  subjective  physical 
examinations 

18.  SPECIAL  SERVICES  REQUESTED:  prioritization  given 

to  patients  that  does  not  relate  to  medical  need 

19.  SUMMARY  OF  SERVICES:  a  total  of  all  hospital  pro¬ 

cesses  that  relate  to  patient.  Some  may  be  con¬ 
sidered  standard,  while  others  are  modified  for 
specific  diagnostic  or  therapeutic  purposes. 

20.  UPDATE  OF  PATIENT  INFORMATION:  results  of  a 

variety  of  hospital  services  that  provide  informa¬ 
tion  relevent  to  the  status  of  the  patient 

21.  MEDICAL  TRANSFER:  any  movement  of  an  inpatient  to 

another  medical  facility  and  the  related  paper  work 

22.  CASUALTY:  the  processes  related  to  admission  for 

non  microbial  reasons 

23.  MEDICAL  BOARDS:  a  special  non  treatment  review 

conducted  to  determine  status  of  patient 

24.  AIR  EVAC:  the  movement  of  patients  by  military 

aircraft  that  has  an  attending  physician 


Table  III-l(b).  Process  Listing 
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Figure  I1I-1.  Function/Process  Matrix 


developer  should  not  accept  these  findings  as  gospel  until 
they  are  reviewed  with  the  users  for  confirmation.  Their 
confirmation  or  refute  is  essential  to  the  building  process 
of  the  logical  design.  Since  several  of  the  users  did  not 
feel  the  processes  analyzed  were  applicable  to  their  specif¬ 
ic  area  they  were  (the  users)  requested  to  produce  sketches 
that  depicted  how  they  thought  their  area  affected  informa¬ 
tion  flow.  (The  reader  is  reminded  that  this  step  occured 
after  the  primary  interviews  were  completed.)  To  facili¬ 
tate  this  process  it  was  recommended  that  they  reference 
specific  documents  that  flow  through  their  area  by  origin, 
any  manipulation  and  where  the  document  went  to  next.  As  an 
additional  input  it  was  requested  that  the  resources  of 
materials,  money,  facilities  and  personnel  serve  as  the 
backdrop  they  develop  their  sketches  from.  This  approach  was 
expected  to  yield  additional  processes  that  had  not  been 
identified  previously.  It  did  satisfy  this  goal.  The  addi¬ 
tional  processes  identified  were:  medical  transfer  (21), 
casualty  (22),  medical  boards  (23)  and  air  evac  (24).  To 
give  the  reader  an  idea  of  the  simplicity  of  the  sketches 
Figure  III-2  is  provided. 


UCA  (F-WARDS) 

PERSONNEL 
(F-CBPO ) 

FUNCTION  AREA  THAT 
PERFORMS  A  PROCESS 

ON  INCOMING  DATA 

USM  REPORT 
(T-HIGHER 
HQTRS ) 

1 _ 

Figure  III-2.  Sample  of  Process  Sketches 


III-7 


Since  additional  processes  were  uncovered  it  was 
necessary  to  repeat  the  functional  area/process  matrix  along 
with  a  review  by  the  users.  It  is  stressed  that  this  pro¬ 
cedure  should  be  repeated  until  the  users  are  confortable 
with  the  associations  depicted.  This  establishment  of  pro¬ 
cess  identity  and  connectivity  provides  constraints  nec¬ 
essary  in  developing  a  logical  design. 

DATA  ANALYSIS 

The  next  step  in  building  this  data  base  system  is 
identifying  the  data  created,  controlled  and  used  by  the 
processes  made  known  in  the  previous  section.  The  majority 
of  data  elements  have  already  been  identified.  This  was 
accomplished  using  techniques  presented  in  the  previous 
chapter.  Since  the  volume  of  data  elements  is  too  big  to 
manipulate  in  a  matrix,  it  was  necessary  to  reduce  the  data 
into  specific  types.  Once  the  unwieldiness  of  the  data  was 
overcome  it  was  possible  to  relate  the  data  types  to  the 
process  In  a  matrix. 

The  categories  used  in  this  paper  are:  personal  data, 
time  related  data,  identifier  data,  statistical  data,  non 
personal  data  and  logic  control  data.  The  meanings  attached 
to  these  data  types  are: 

PERSONAL  DATA  -  data  that  describes  and/or  gives  value  to 

humans,  (e.g.,  street,  city,  zip,  state, 
sex,  etc.) 

TIME  RELATED  DATA  -  data  that  reflects  a  means  of  tracking 

time.  (e.g.,  date,  st:time,  stp:time, 
etc . ) 
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IDENTIFIER  DATA  -  data  that  possesses  a  possible  unique 

quality.  (e.g.,  ssan,  key#,  id#,  room#, 
etc . ) 

STATISTICA1  DATA  -  data  that  reflects  a  history  or  a  sum¬ 
mary.  (e.g.,  prev: bed :dys,  prev: qtr :dys, 
#air: in ,  etc . ) 

NON-PERSONAL  DATA  -  data  that  relates  to  facilities  and 

machinery,  (e.g.,  #beds,  #rm,  civrmtf, 
phone,  etc .  ) 

LOGICAL  CONTROL  DATA  -  data  that  is  tracked  by  a  yes  no  or 

on  off  response.  (e.g.,  availtbed, 
blckrbed,  xraytreq,  rec:req,  etc.) 

It  must  be  stressed  to  the  reader  that  the  meanings 
attached  to  these  categories  as  well  as  the  categories  are 
not  the  only  ones  possible.  They  are  presented  to  demon¬ 
strate  how  this  data  base  was  developed  and  to  give  the 
reader  a  method  for  analyzing  data.  But  no  matter  what 
categories  and  meanings  are  chosen  it  is  recommended  that 
the  categories  be  restricted  to  seven  (7)  or  less  for  ease 
of  control. 

Once  the  categories  are  Identified  and  the  data  ele¬ 
ments  grouped  another  matrix  can  be  constructed.  This  is  a 
category/process  matrix  (Figure  III-3).  The  information 
gained  from  this  matrix  is  the  identification  of  data  that 
is  shared  by  the  processes,  hat  is  unique  to  a  process  and 
that  could  have  future  uses  in  an  Information  process.  As 
an  added  mode  to  gain  a  better  understanding  of  the  data 
categories  and  processes,  entries  in  the  matrix  should  be  in 
the  letters  ’C’  and  ’U’  to  indicate  which  processes  create 
the  data  and  which  use  it.  The  results  of  this  method  are: 


III-9 


«> 


identification  of  duplicated  data,  potential  access  pro¬ 
cedures,  and  data  groupings  for  relations.  To  confirm  in¬ 
terpretations  found  in  the  category/process  matrix  another 
matrix  was  constructed.  This  matrix  was  a  functional 
area/category  matrix  (Figure  III— -4 ) .  The  intent  behind  this 
process  is  to  lend  credence  to  the  shared  data  findings;  it 
does  not  confirm  them.  The  findings  were  as  expected  since 
a  confirmation  would  emerge  only  when  the  total  system  is 
implemented  and  users  become  familiar  with  the  DBMS  and  its 
potential  uses.  (Ref  14,  p  144) 

However,  the  information  gained  from  the  previous  pro¬ 
cess  is  too  much  to  begin  developing  relations.  To  overcome 
this  problem  it  was  necessary  to  segment  the  data.  The 
operation  used  to  break  the  data  up  involved  rearranging  and 
grouping  the  twenty-four  processes  into  subsystem  types.  The 
types  used  in  this  paper  are:  subsystems  that  create  data 
without  using  other  subsystems,  subsystems  that  create  data 
using  other  subsystems  and  subsystems  that  are  user  only. 
The  catalyst  used  was  an  association  between  the  processes 
and  the  following  resources:  materials,  facilities,  person¬ 
nel  and  money.  When  the  matrix  (Figure  III-5)  for  this  re¬ 
grouping  is  constructed  the  various  subsystems  emerge.  How 
easily  these  groupings  are  recognized  is  dependent  on  how 
thorough  an  understanding  you  have  of  the  hospital  processes 
and  the  data  required  to  support  them. 

What  was  found  was  the  following:  ADMINISTRATIVE  INFOR- 
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CATEGORY 


Figure  III-4.  Functional/Category  Matrix 


Figure  III-5-  Subsystem  Matrix 


MATION,  EXPENDITURE,  CASUALTY  and  AIR  EVAC  were  independent 
data  subsystems,  the  areas  blocked  by  rectangles  are  depen¬ 
dent  data  subsystems  and  no  user  data  subsystems  were  found. 
Thus  by  starting  with  the  independent  systems  and  then  the 
dependent  the  relation  development  was  easier. 

Since  the  preceeding  matrices  resolved  the  questions 
of  redundancy  and  of  which  areas  to  begin  examining  for 
relations,  the  data  elements  were  put  into  a  data  diction¬ 
ary.  These  data  dictionary  entries  were  made  as  complete  as 
possible  to  reduce  confusion  if  modifications  to  the  system 
became  necessary. 


KEYS 

The  next  step  in  the  development  process  of  a  logical 
design  for  WPAFB-KC  involves  identification  of  key  data 
elements  that  uniquely  identify  a  particular  and  distinct 
grouping  of  data  elements. 


Keys  are  data  elements  used  throughout  the 
organization  to  identify  objects,  create  other 
data,  or  reference  other  data.  There  are  two 
types  of  keys: 

Unique  keys  are  data  elements  that 
identify  a  particular  and  distinct 
thing  or  object  (e.g.,  social  se¬ 
curity  number,  order  number,  custo¬ 
mer  number,  etc . ) 

Nonunique  keys  (composite  key)  are 
collections  of  data  elements,  unique 
in  their  use,  that  receive  their 
identity  through  two  or  ir  re  unique 
keys  (e.g.,  an  inventory  that  is 
Identified  through  the  unique  keys. 

Item  number,  and  warehouse  lo¬ 
cation.)  (Ref  3,  P  274 ) 


III-14 


These  keys  usually  exist  in  the  content  data  elements.  The 
term  "content  data  elements"  is  used  in  the  following  con¬ 
text:  data  elements  that  are  commonly  identified  with  a 
process.  This  determination  process  of  key  data  elements 
has  been  expedited  by  the  category  procedure  employed  in 
reducing  the  data  elements.  The  category  "Identifier  Data" 
lists  the  primary  choices.  Capitalizing  on  this  listing 
coupled  with  a  little  ’common  sense’  key  data  elements  are 
found  existing  within  most  of  the  content  data  groupings. 
However,  in  some  cases,  it  is  difficult  or  inconvenient  to 
use  available  attributes  as  the  entity  identifier.  What  is 
done  is  to  create  an  artificial  attribute  which  can 
positively  identify  the  content  data.  Examples  are  "SSAN", 
"ROOM#",  "BED#"  and  "WARD#". 

The  results  of  all  the  preceding  procedures  is  a  suc¬ 
cessful  division  of  the  data  into  logical  groupings.  These 
groupings  allow  for  simultaneous  use  of  certain  content  data 
items  which  have  the  same  key  in  the  established  operational 
scheme.  Thus  a  reduction  in  the  number  of  information  items 
manipulated  is  realized  by  considering  only  groups  of 
fields.  This  is  a  considerable  savings  when  the  manipula¬ 
tion  that  is  involved  in  a  hospital  information  system  could 
involve  several  thousand  data  fields.  (Ref  19,  pl^l) 

An  example  of  a  logical  grouping  is: 

PROVIDERS:  SSAN,PROV#,  SPEC-CODE,  CLINIC# 


i 
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THIRD  NORMAL  FORM 


Even  though  the  data  has  successfully  been  divided 
there  are  still  problems  in  its  composition.  These  problems 
can  be  grouped  into  three  general  types:  insertion,  dele¬ 
tion,  and  update.  To  overcome  these  problems  the  process  of 
converting  the  data  to  "third  normal  form"  (3NF)  is  em¬ 
ployed  . 

"Before  defining  third  normal  form  (3NF),  we  need  a 
preliminary  definition  for  a  'prime  attribute'.  An  attri¬ 
bute  A  in  relation  scheme  R  is  a  prime  attribute  if  A  is  a 
member  of  any  key  for  R  (there  may  be  many  keys).  If  A  is 
not  a  member  of  any  key,  then  a  is  nonprime."  (Ref  21,  p 
235) 


A  formal  definition  of  3NF  is:  "A  relation  scheme  R  is 
in  3NF  form  if  and  only  if  there  does  not  exist  a  key  X  for 
R,  a  set  of  attributes  Y  C  R,  and  a  nonprime  attribute  A  of 
R  not  in  X  or  Y,  such  that 

1.  X-to-Y  holds  in  R, 

2.  Y-to-A  holds  in  R,  but 

3.  Y-to-X  does  not  hold  in  R. 

If  Y  is  a  subset  of  X,  and  therefore  by  (3),  Y  is  a 
proper  subset  of  X,  then  R  is  said  to  have  a  partial  depen¬ 
dency.  If  Y  is  not  a  subset  of  X,  then  R  has  a  transitive 
dependency.  If  R  satisfies  the  above  condition  whenever  Y  C 
X,  but  not  necessarily  otherwise,  then  R  is  said  to  be  in 
second  normal  form."  (Ref  21,  p  187) 


III-16 


To  show  how  the  logical  examples  are  transformed  to  3NF 
the  following  specimens  are  provided: 

PROVIDER:  (SSAN,  PROV#,  SPEC-CODE,  CLINIC#) 

becomes 

1.  PROVIDERS:  (SSAN,  PROV# ) 

2.  PROVIDERS-SPECIALTY :  (PROV#,  SPEC-CODE) 

3.  PROVIDER-CLINIC:  (PROV#,  CLINIC#) 

The  final  product  develped  after  putting  into  3NF  is  in 
the  appendix.  A  graphic  representation  of  the  logical  de¬ 
sign  is  also  provided  in  Figure  III-6. 

SAMPLES  OF  DATABASE  USE 

To  demonstrate  how  information  is  extracted  from  the 
relational  model  developed  in  this  paper  three  examples  are 
provided.  This  degree  of  inquiry  ranges  from  the  simple  one 
relation  query  to  a  multiple  relation  query.  (Note:  In  the 
following  queries  pseudo  code  is  used  to  represent  how 
information  is  extracted  from  the  data  base.) 

Example  One: 

The  Inspector  General  Team  (IG)  representa¬ 
tive  is  conducting  a  spot  check  of  rooms.  He 
wants  to  know  when  the  last  inspection  was  done  on 
rooms  10,  30,  100.  To  accomplish  this  task  one 

could  refer  to  a  log  book  for  the  information  or 
the  DBMS  could  be  queried  in  the  following  way: 

Use  the  relation  "Rooms" 

Select  records  with  room  numbers  of: 

"10",  "30",  "100". 
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Project  out  "insp:date". 

The  results  would  be  the  dates  of  inspection. 


Example  Two: 

Suppose  the  same  inspector  now  asks  for 
the  number  of  beds  on  Ward  ”3"  ,  a  Burn  Center, 
that  are  available  right  now.  His  reason  is  a 
simulation  of  an  aircraft  accident  in  which  six 
crew  members  have  severe  burns  which  need  immedi¬ 
ate  care.  The  reason  for  the  urgency  is  that  the 
aircraft  transporting  the  victims  has  damaged 
landing  gear  and  can  make  only  one  landing  and 
WPAFB-MC  is  the  closest  hospital.  This  type  of 
query  can  be  answered  by  conventional  systems  but 
not  as  quickly  as  a  DBMS  could.  The  DBMS  could  be 
queried  in  the  following  way: 

Use  relations  "Rooms"  and  "Bed  Status". 

Select  from  "Rooms"  where  ward#  =  '3'. 

Join  the  result  with  "Bed  Status". 

Select  where  avail: bed  =  "yes". 


Example  Three: 

Doctor  X  calls  in  sick.  He  is  not  sure  what 
his  schedule  was  for  this  day.  He  provides 
his  social  security  number  since  that  will  help 
locate  Information  on  how  to  deal  with  his  absence. 

Select  from  "Providers"  where  ssan  =  Dr.  X’s. 

This  gives  his  provider#. 

Select  from  "Providers-Specialty"  where  prov# 

*  Dr.  X’s. 

This  gives  his  spec: code. 

Select  from  "Provider-Clinic"  where  prov# 

=  Dr.  X’s. 

This  yields  a  list  of  clinics  to  notify  that 

Dr.  X  will  not  be  in. 
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Select  from  "Appointment"  where  prov#  and 
date  =  Dr.  X's  and  today's  date. 

Select  from  "Provider-Specialty"  where 
spec: code  =  Dr.  X's. 

If  any  doctor  is  on  staff  that  has  Dr.  X's 
specialty  the  appointments  can  be  reworked. 

If  no  alternates  are  found  then  the  following 
is  necessary: 

Join  the  list  of  appointments  and  "Patient" 
where  ssan  +  dep:code  match. 

This  will  give  the  phone  numbers  to  call  for 
a  reschedule. 

Select  from  "Administrative"  where 

prov# (attn:phy)  =  Dr.  X's. 

This  will  give  a  list  of  ssan-dep : code  and 
ward#s  that  Dr.  X  is  the  attending  physcian. 
Join  list  of  ward#s  with  "Ward". 

This  gives  the  supervisor : ssan  for  that  ward. 
Join  list  of  supervisors'  ssans  with 
"Personnel" . 

This  gives  the  duty  phone  of  the  supervisors 
to  notify  that  Dr.  X  will  not  be  in. 


Summary  of  Process 

This  chapter  has  presented  a  method  for  organizing  data 
into  a  relational  information  system  that  will  support 
WPAFB-MC.  All  the  processes  presented  involved  using  asso¬ 
ciations  that  exist  when  data  is  grouped  by  resources  and 
specified  processes.  Matrices  were  employed  to  make  the 
associations  easier  to  identify.  As  each  process  is  com¬ 
pleted  the  system  developer  obtains  a  clearer  idea  of  how  to 
begin  organizing  data  into  logical  groupings  which  are  in  at 
least  3NF. 
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IV.  IMPLEMENTATION  PLAN 


OVERVIEW 

The  entire  process  for  developing  a  DBMS  is  useless 
unless  some  type  of  overall  plan  is  made  available  for 
implementation.  Such  a  plan  has  been  developed  as  a  result 
of  callaboration  with  Mr  Raymond  E.  Girard,  Chief,  Medical 
Computer  Systems  Office,  WPAPB-MC.  This  plan  outlines  the 
time  process/sequence  for  implementation.  What  follows  is 
the  Purpose,  Scope,  Coordination  and  Documentation,  and 
Responsibility  descriptions  of  the  plan. 

PURPOSE 

As  stated  before,  the  purpose  of  this  plan  is  to  pro¬ 
vide  general  guidance  and  information  for  those  Medical 
Treatment  Facilities  (MTF)  that  choose  to  implement  the 
WPAFB-MC  DBMS.  This  plan  sets  forth  the  procedures  to  be 
used  in  the  conversion,  implementation  and  evaluation  of  the 
DBMS.  This  plan  also  outlines  procedures  to  determine  the 
adequacy  of  hardware  and  software  resources,  functional 
procedures  and  documentation  of  the  system. 

SCOPE 

This  plan’s  guidance  will  pertain  to  the  actions  to  be 
accomplished  by  the  MTF.  However,  its  scope  is  applicable 
to  liason  organizations  such  as  Civil  Engineering,  the  Base 
Data  Processing  Installation  (DPI),  Procurement,  Communica¬ 
tions,  Major  Command  Headquarters,  and  the  TRIMIS  Program 
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Management  Office.  This  document  will  outline  the  criteria 
and  procedures  associated  with  the  successful  implementation 
of  the  functional  system.  There  is  no  intent  to  task  other 
agencies,  only  the  implementing  MTF.  The  responsibilities 
involving  other  agencies  should  be  derived  by  mutual  agree¬ 
ment  of  representatives  of  those  agencies. 

COORDINATION  AND  DOCUMENTATION 

Mr  Girard's  experience  in  computer  systems  has  shown 
that  the  implementation  of  a  DBMS  within  any  MTF  constitutes 
a  significant  amount  of  work.  Many  of  the  tasks  associated 
with  this  implementation  are  frequently  understated  or 
grossly  underestimated  due  to  the  MFTs '  inexperience  with 
implementing  automated  systems.  The  implementation  of  an 
information  system  requires  precise  management  planning 
because  of  its  impact  throughout  the  MTF.  Besides  the 
physical  and  technical  problems  associated  with  a  systems 
implementation  there  are  many  people  problems  (e.g.,  combat¬ 
ting  resistance  to  change)  that  must  be  solved.  There  can 
not  be  too  much  emphasis  placed  on  human  factors  and  precise 
workflow  and  methods  engineering.  Paralleling  the  human 
factors  problem  is  the  need  to  work  with  other  organiza¬ 
tions.  It  will  be  necessary  to  gain  and  maintain  technical 
assistance  from  various  local  organizations  such  as  the 
local  DPI  and  Civil  Engineering  as  well  as  to  assure  support 
from  higher  commands  and  the  responsible  vendor. 

Although  certain  time  guidelines  are  provided  within 
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this  plan,  it  will  be  necessary  to  use  personal  experience 
to  alter  lead  times  as  appropriate.  It  is  essential  that 
memoranda  and  documentation  of  all  actions  taken  during  the 
implementation  are  kept.  This  will  serve  to  improve  under¬ 
standing  among  the  individual  organizations  and  units  of 
responsibility. 

It  must  be  kept  in  mind  that  this  plan  should  be  sup¬ 
plemented  by  portions  of  regulations  within  each  service 
that  apply  to  data  automation  implementation.  An  example  of 
this  is  Annex  7  and  9  from  AFM  300-6  which  provides  manage¬ 
ment  and  implementation  checklists. 

RESPONSIBILITY 

To  ensure  the  success  of  this  undertaking  it  is  neces¬ 
sary  that  the  commander  of  the  MTF  have  overall  responsibil¬ 
ity  for  local  implementation  of  this  plan  through  his/her 
appointed  project  officer.  The  commander  should  take  appro¬ 
priate  action  to  assure  the  efficient  accomplishment  of  the 
implementation  plan  by  his  subordinate  staff. 

A.  MTF  DBMS  Project  Officer  will: 

(1)  Serve  as  the  primary  DBMS  project  office  and 
coordinator  of  all  activities  relating  to  the  implementation 
of  DBMS. 

(2)  Provide  to  the  Equipment  Control  Office  (ECO), 
of  the  DPI,  sufficient  documentation  to  accept  or  reject  the 
DBMS  hardware  and  software. 
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B.  Directorate  Hospital  Services  (SGH):  As  primary 

user  of  the  DBMS  capability,  provides  personnel  and  manage¬ 
ment  resources  required  to  accomplish  the  day  to  day  opera¬ 
tion  of  the  DBMS. 

C.  Data  Processing  Department: 

(1)  Provide  to  the  Equipment  Control  Officer,  cer¬ 
tification  of  acceptability/non-acceptability  of  DBMS  soft¬ 
ware  and  supporting  documentation. 

(2)  Provide  guidance  to  the  appropriate  command  on 
all  facets  pertinent  to  implementation. 

(3)  Evaluate  acceptance  data  and  accept  or  reject 
hardware  and  software. 

(4)  Act  as  primary  contact  with  the  vendor 
representatives  for  contractual  matters  as  specified  by  AFM 
300-6. 

D.  Command  Data  Automation: 

(1)  Advise  and  assist  in  determination  of  the  suit¬ 
ability  of  contractor  provided  data  processing  equipment 
(DPE)  configuration  management. 

(2)  Assist  MTF  and  computer  operations  personnel  in 
interpreting  and  conforming  with  the  provisions  of  appro¬ 
priate  regulations. 

E.  All  above  named  organizations  will:  provide  repre¬ 
sentation  at  the  dally  acceptance  test  meetings. 

The  actual  plan  is  provided  in  Annexes  A-F.  (Note:  ’+' 
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symbol  Is  used  to  delineate  days  after  actual  implementation 
of  the  DBMS  and  symbol  is  used  to  delineate  days  prior 
to  completion  of  the  DBMS.) 
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V.  DBMS  CAUSES  A  NEW  STRUCTURE 


OVERVIEW 

This  chapter  presents  evidence  to  the  reader  of  the 
necessity  to  have  the  WPAFB-MC's  Data  Processing  Department 
(DP)  more  prominent  in  the  command  structure.  The  reality 
of  this  change  is  brought  about  by  the  emergence  of  a  data 
base  management  system  coupled  with  the  predictable  economic 
maturation  an  enterprise  (civilian  or  military)  will  exper¬ 
ience  in  a  computer  environment.  Areas  covered  which  depict 
the  structure,  growth  and  management  change  are:  The  DBA  ~ 
Its  Structure  &  Purpose,  Technique  To  Determine  Growth  And 
Its  Link  To  Management,  and  finally  a  Prudential  Approach  By 
Management . 

THE  DBA  -  ITS  STRUCTURE  AND  PURPOSE 

Inherent  to  any  attempt  to  convince  anyone  of  the  need 
for  change  is  the  requirement  to  establish  a  common  starting 
point.  This  point  became  quite  obvious  in  discussions  with 
the  TRIMIS  office's  representatives  as  well  as  with  non¬ 
computer-literate  managers  within  the  administrative  sec¬ 
tions  of  WPAFB-MC.  There  seemed  to  be  a  lack  of  under¬ 
standing  of  what  a  data  base  management  system  did  and  why 
it  would  need  a  Data  Base  Administrator  (DBA).  In  fact  the 
two  questions  most  uttered  were:  "What  is  a  data  base 

management  system?"  and  "What  is  a  Data  Base  Administrator?" 
The  first  of  these  two  questions  was  covered  and  demon- 


strated  in  chapters  two  and  three.  The  latter  will  be 
covered  in  this  chapter. 

A  DBA  is  not  necessarily  a  single  person,  (as  the  name 
seems  to  imply)  but  a  function  which  is  created,  organized, 
and  staffed  to  manage  the  data  'resource'.  (Ref  14,  p  121) 
In  the  case  of  WPAFB-MC  a  DBA  function  would  have  to  be 
sustained  by  several  specialized  support  areas.  These  areas 
would  involve  a  Software  Expert,  Application  and  Systems 
Specialist  and  a  Data  Base  Technical  Specialist.  What  each 
of  these  positions  does  is  dependent  on  the  different 
stages  of  the  data  base  development  process.  Atre  has 
distinquished  these  development  stages  into  six  levels. 
These  areas  are: 

1.  Design  Phase 

2.  Physical  creation  of  the  data  base. 

3.  Conversion  of  the  existing  data  sets 
and  applications  to  match  the  newly 
created  data  base. 

4.  Integration  of  the  converted  appli¬ 
cations  and  of  the  new  applications 
into  the  data  base. 

5.  Operational  phase. 

6.  Growth,  change  and  maintenance  phase. 

(Ref  2,  p  53) 

Responsibilities  of  Sections 

A.  Software  Expert.  The  Software  Expert  Is  respon¬ 
sible  for  insuring  that  documentation  and  develpment  of 
programs  is  done.  This  person  in  this  position  must  be  able 
to  determine  what  impacts  programming  styles  will  have  on 
memory  use  as  well  as  retrieval  times.  In  addition  he/she 
must  evaluate  the  credibility  of  backup,  recovery,  security. 


and  privacy  procedures. 

B.  Applications  and  Systems  Specialist.  This  is  the 
functional  expert  who  can  translate  and  develop  the  logical 
structures  of  individual  departments  in  an  organization  into 
a  physical  structure  within  the  computer’s  data  base.  In 
addition  this  position  serves  as  support  to  the  software 
expert  in  performance  characteristics  of  the  DBMS.  Such 
support  would  be:  checking  for  security,  privacy  and  access 
control  violations. 

C.  Data  Base  Technical  Specialist.  This  area  would 
encompass  the  communication  mechanisms.  That  is  maintaining 
a  data  dictionary/directory  system,  maintaining  ancillary 
records,  as  well  as  coordinating  all  meetings  involving  the 
different  functions  in  the  data  base  environment. 


Figure  V-l.  Schematic  of  DBA  Sections 
The  aforementioned  three  areas’  responsibilities  would 
be  in  part  and/or  entirety  throughout  all  levels  of  the  DBMS 
development . 


To  coordinate  and  manage  these  functional  areas  it  is 


necessary  to  incorporate  them  under  the  DP/DBA.  This  will 
ensure  that  standards  will  be  set  for  accomplishing  suc¬ 
cessful  and  efficient  use  of  the  data  and  its  supportive 
function  to  the  hospital. 


:  TECHNICAL  :  :  :  : 

:  CHANGES  :  :  :  : 

:  IN  SOFTWARE:-* - H :  DP/DBA  MANAGEMENT 

:  &  HARDWARE  :  :  :  : 

:  DEVELOPMENT:  :  :  : 


:  DATA  PROCESSING: 

:  USER  : 

:  (APPLICATION  &  : 

:  DEVELOPMENT  : 

:  COMMUNITY  : 

Figure  V-2.  Linking  of  DP/DBA  to  Management 

MODEL  WHICH  LINKS  MATURATION  PROCESS  OP  DP  TO  MANAGEMENT 

As  the  data  base  grows  it  will  establish  links  with  all 
functions  of  the  hospital.  This  in  turn  means  that  the  DP 
center  will  become  a  significant  part  of  the  hospital’s 
operations.  Because  of  this  evident  trend  there  is  a  need 
to  predict  when  the  DP  department  reaches  a  point  where  the 
data  resource  moves  to  a  front-and-center  position.  It  would 
become  recognized  as  an  essential  asset  to  the  hospital,  and 
thus  critical  to  fulfilling  the  directed  goal  of  the  best 
quality  medical  care  possible.  (Ref  11,  p  19) 

Gibson  and  Nolan  did  extensive  research  in  this  area  of 
DP  growth  as  it  relates  to  management.  Their  investigations 
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revealed  that  DP  budgets  could  be  used  to  predict  maturation 

of  the  DP  environment  as  it  relates  to  management. 

Although  the  cost  of  hardware  on  a  per-unit 
basis  is  declining,  total  data  processing 
costs  continue  to  increase  dramatically.  Prom 
1970  -  1978,  aggregate  United  States  data 

processing  budgets  rose  almost  two  and  one- 
half  times  from  a  total  of  $17  billion  1970  to 
$42  billion  1978.  This  trend  is  expected  to 
continue  in  the  1980’ s.  Aggregate  spending  for 
data  processing  is  expected  to  top  $78  billion 
in  1983  -  almost  double  the  amount  spent  in 

1978  (International  Data  Corporation,  1980). 

This  means  that,  as  more  and  more  corporate 
applications  are  put  on  the  computer,  the  DP 
is  managing  a  larger  budget  and  the  data 
center  is  becoming  a  very  visible  part  of 
corporate  operatons.  (Ref  11,  p  24) 

This  approach  is  most  fortuitous  when  discussing  with  man¬ 
agement  the  level  of  support  that  the  DP  needs  to  effective¬ 
ly  perform  its  job,  because  it  provides  a  common  ground  for 
both  sides. 


It  is  this  common  ground  which  prevents  the  all  too 

often  occurence  of  the  following  stereotypic  views. 

From  the  viewpoint  of  the  executive  vice  president: 

’’The  DP  manager  always  waffles  around  when  he  has 
to  explain  his  area." 

From  the  view  point  of  the  DP  manager: 

"The  excutive  vice  president  never  seems  to 
understand  what  the  department  can  do."  (Ref  16,  p  76) 


Nolan's  research  revealed  that  there  are  six  stages  of 
growth  from  inception  of  the  DP  center  to  maturity.  These 
stages  are: 


1.  INITIATION 

2.  CONTAGION 

3 .  CONTROL 

4 .  INTEGRATION 

5.  DATA  ADMINISTRATION 

6.  MATURITY  (Ref  16,  p  117) 


These  stages  are  depicted  graphically  in  Figure  V-3  repro¬ 
duced  from  Nolan’s  article  in  Harvard  Business  Review,  Apr- 
May  '79- 
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Nolan's  view  is  that  the  basis  for  these  stages  of 
organizational  fit  can  be  determined  from  a  graph  using  DP 
budget  versus  time  from  initial  investment  to  mature  opera¬ 
tion.  "The  graph  produced  forms  an  ’S’  shaped  curve  (refer 
to  Figure  V-3  ).  The  turnings  of  the  curve  correspond  to 
the  main  events  -often  crisis-  in  the  life  of  the  DP 
function  that  signal  important  shifts  in  the  way  the  com¬ 
puter  resource  is  used  and  managed."  (Ref  11,  p  78) 


Before  using  the  findings  and  predictions  this  graph 
provides  as  it  relates  to  WPAFB-MC,  it  is  necessary  to 
examine  how  a  DP  center  grows.  The  types  of  growth  usually 
are  in  the  form  of  new  equipment,  specialization  of  person¬ 
nel,  management  techniques  and  organizations,  and  software 
applications.  This  is  Important  for  management  to  note  espe¬ 
cially  when  one  considers  that  as  you  add  to  a  system  its 
complexity  increases.  A  graphic  demonstration  of  this  con¬ 
cept  is  provided  in  Figure  V-{ 


3  NODES  >=  3  CONNECTORS 


4  NODES  *  6  CONNECTORS  6  NODES  -  l5  CONNECTORS 

Figure  V-4.  Graphic  Demonstration  of  Growth 
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From  the  point  provided  by  the  figure  coupled  with  an 
examination  of  prevailing  conditions  in  WPAFB-MC’s  DP 
department  one  can  easily  perceive  that  a  transition  between 
stage  two  and  three  is  transpiring.  This  is  a  critical 
point  in  the  evolution  of  the  DP  function  within  the  hos¬ 
pitals  information  support  structure.  The  gravity  of  the 
situation  is  best  characterized  by  the  following: 

Stage  2  is  a  period  of  contagious  and 
unplanned  growth,  characterized  by 
growing  responsibilities  for  the  DP  di¬ 
rector,  loose  (usually  decentralized) 
organization  of  the  DP  facility,  and  few 
explicit  means  of  setting  project  prior¬ 
ities  or  crystallizing  plans.  (Ref  11,  p 
81) 

The  next  stage  of  development  is  considered  by  many  as 
a  transition  stage.  The  DP  center  no  longer  is  dealing  with 
cost-reduction  of  applicatons  of  specialized  use.  The  em¬ 
phasis  turns  toward  integrating  the  functions  into  DBMS  and 
development  of  projects  aimed  at  improving  operations  and 
the  quality  of  unprogrammed  and  strategic  decisions.  The 
influence  of  the  computer  will  be  felt  throughout  the  organ¬ 
ization  at  all  levels.  (Ref  11,  p  85) 

A  PRUDENTIAL  approach  by  hospital  management 

As  presented  in  the  previous  section  the  DP  center  is 
predicted  to  be  on  the  verge  of  a  dramatic  change  in  its 
function  and  character.  In  fact  one  would  expect  the  DP 
centers  in  all  military  hospitals  to  experience  the  same 
growing  pains  that  WPAFB-MC  is  beginning  to  have.  But,  what 
is  this  new  function  and  character  that  will  begin  emerging 
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at  WPAFB-MC?  It  is  the  transition  from  computer  management 
to  that  of  data  resource  management. 


With  the  introduction  of  data  base  tran¬ 
sition  in  stage  3»  an  important  shift  in 
emphasis  goes  from  managing  the  computer 
to  managing  the  company’s  data  resources. 
Obviously,  this  transistion  does  not 
occur  all  at  once.  It  appears  first  in 
the  analysis  of  the  late  stage  2  applica¬ 
tions  portions  and  as  a  result  of  the 
requirements  to  restructure  so  all  of  the 
applications  can  be  tied  together  effi¬ 
ciently. 

The  transition  also  becomes  apparent 
during  the  implementation  of  controls. 
Difficulties  with  charge-out  systems  that 
are  computer-oriented  start  management 
searches  for  alternative  ways  to  achieve 
user  accountability.  This  often  leads  to 
the  conclusion  that  the  user  can  be 
accountable  for  the  functional  support, 
but  data  processing  must  be  accountable 
for  management  of  shared  data. 

The  key  idea  is  to  recognize  the 
importance  the  shift  in  management  empha¬ 
sis  from  the  computer  to  data  and  then 
to  develop  application  and  planning  and 
control  systems  to  facilitate  the  transi¬ 
tion.  Applications  should  be  structured 
to  share  the  data;  new  planning  and  con¬ 
trol  should  be  data-oriented.  (Ref  16,  p 
124) 


It  is  on  this  last  part  of  the  above  quote  that  the  key 
to  meeting  WPAFB-MC ’s  mission  is  identified,  and  that  is  the 
need  to  shift  managements  emphasis  to  the  data  and  more 
authority  to  the  DP  manager.  This  additional  authority 
would  increase  the  DP’s  participation  in  hospital  planning. 
It  would  give  added  perspective  to  other  managers  of  the 
importance  data  processing  has  to  the  hospital  in  meeting 
its  defined  needs  now  and  in  the  future.  (Ref  23,  p  204) 
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The  type  of  support  being  suggested  should  come  from 
the  position  within  the  hospital  which  has  the  most  to  gain 
from  effective  and  efficient  use  of  the  data.  This  position 


is  that  of  the  hospital  commander. 

According  to  APR  168-4  the  commander  of  the  hospital 
has  direct  responsibility  for  the  following  areas:  Direct¬ 
orate  Aerospace  Medicine,  Directorate  Physiological  Train¬ 
ing,  Directorate  Hospital  Services,  Directorate  Veterinary 
Services,  Directorate  Dental  Services,  and  Directorate  Medi¬ 
cal  Education.  Because  these  areas  are  becoming  more 
dependent  on  computer  support  to  maintain  their  quality  of 
care,  involvement  by  the  DP  director  will  be  necessary. 
Therefore  the  DP  center  can  no  longer  be  considered  a 
support  function.  It  should  be  thought  more  in  terms  of  a 
planning  function. 

The  recognition  of  the  DP  as  a  line 
(planning)  function  is  also  a  realization 
by  users  and  management  that  the  DP  and 
staff  and  the  computer  are  indispensable 
to  the  company's/hospital's  operation  and 
that  the  computer  manager  should  rightly 
be  included  in  the  planning  for  the  com¬ 
pany/hospital.  (Ref  14,  p  39) 

With  this  new  channel  of  support  the  DP  manager  will  be  able 
to  "understand  how  current  actions  will  affect  both  the 
solution  of  current  problems  and  the  accomplishment  of  goals 
for  the  future."  (Ref  14,  p  21)  This  is  especially  true 
when  the  proposed  data  base  becomes  a  reality. 

...  a  power  whereby  its  applications 
can  affect  the  strategy  and  structure  of 
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the  company  as  a  whole.  In  a  company 
where  a  working  data  base  can  be  used  to 
back  up  the  corporate  planning  process, 
for  example,  corporate  planning  assumes  a 
somewhat  different  shape  from  what  it 
does  in  a  company  that  has  no  such  data 
base  available.  This  is  clearly  a  point 
at  which  a  person  at  the  vice-pres¬ 
idential  level  (or  even  the  presidential 
level)  must  accept  responsiblity  for 
dirrecting  the  evolution  of  the  resource. 
(Ref  11,  p  85) 


This  channel  of  authority  is  also  necessary  to  overcome  the 
natural  political  issues  that  will  surface.  Political  is¬ 
sues  in  this  case  are:  users  losing  personal  control  over 
their  data,  trade-offs  as  to  what  data  elements  need  to  be 
in  the  data  base,  and  the  fear  of  managers  losing  some 
authority  by  acquiescing  to  the  data  base  for  decision 
basing  ability. 

For,  from  a  behavioral  perspective,  po¬ 
litical  issues  dominate  at  this  time  as 
never  before.  Managers  throughout  the 
company  now  see  that  the  applications 
coming  through  the  pipeline  may  affect 
their  own  roles  directly.  In  the  past  it 
was  their  subordinates  who  were  most 
affected,  and  it  was  largely  their  own 
decisions  to  approve  or  not  approve  a 
project,  but  now  a  given  application  may 
be  supported  from  above  and  may  impinge 
on  their  established  patterns  of  work, 
their  decision  making,  and  even  their 
ideas  about  what  it  is  they  do  for  a 
living. 

Because  of  the  nature  of  his  dilemma,  he 
is  bound  to  come  under  fire  from  the 
users-elther  for  allowing  parts  of  his 
department  to  obsolesce,  in  the  name  of 
stability  or  for  introducing  change,  in 
the  name  of  progress  and  the  state  of  the 
art.  His  relationship  and  communications 
with  the  top  must  be  sound  enough  to 
allow  him  to  weather  the  inevitable 
storms  given,  of  course,  that  the  balance 
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he  strikes  between  stability  and  change 
is  indeed  reasonable  in  broad  outline. 

With  long-term  support  from  the  top 
founded  in  such  a  basis,  the  MIS  manager 
is  in  a  position  to  legislate  policies 
internally  that  will  exploit  the  computer 
as  fully  as  possible. 

(Ref  11,  pp  85  &  87) 


From  the  evidence  it  is  easy  to  see  that  the  DP  center 
is  about  to  under-go  a  metamorphosis  that  will  enhance 
managements  decision  capablities.  But  this  is  only  possible 
if  management  heeds  the  premises  presented  and  gives  way  to 
the  idea  of  incorporating  the  DP  center  into  a  directorate 
reporting  to  the  hospital  commander. 


"Science  is  nothing  but  trained  and  organized  com¬ 
mon  sense,  differing  from  the  latter  only  as  a 
veteran  may  differ  from  a  raw  recruit:  and  its 
methods  differ  from  those  of  common  sense  only  as 
far  as  the  guardsman's  cut  and  thrust  differ  from 
the  manner  in  which  a  savage  wields  his  club." 

Thomas  Henry  Huxley,  1825-1895 
Collected  Essays 
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VI.  CONCLUSIONS  AND  RECOMMENDATIONS 


OVERVIEW 

The  previous  chapters  have  demonstrated  that  a  portion 
of  WPAFB-MC’s  information  needs  can  be  supported  by  a  rela¬ 
tional  data  base.  In  addition  a  method  for  accomplishing 
such  a  structure  was  illustrated.  Because  of  these  factors 
it  would  be  possible,  in  the  future,  to  employ  this  approach 
to  create  a  total  hospital  information  system.  WPAFB-MC 
could  exhibit  its  desire  to  meet  future  mission  needs  along 
with  demonstrating  leadership  among  MTFs  by  continuing  the 
process  until  the  total  system  is  developed. 

Conclusions 

It  is  felt  that  the  relational  data  base  would  benefit 
the  hospital  because  it  would  reduce  needless  duplication  of 
data.  It  Is  also  believed  that  such  a  system  would  improve 
reliability  of  information,  decrease  the  need  for  additional 
manpower  slots  and  allow  for  better  control  of  personnel, 
equipment  and  budgets. 

If  follow  on  theses  are  pursued  via  a  module  approach 
large  expenditures  for  independent  contractors  could  be 
reduced  and  thus  lessen  a  portion  of  TRIMIS’  yearly  budget. 
A  final  point  is  that  a  relational  hospital  information 
system  could  support  TRIMIS  requirements  and  have  the  added 
feature  of  being  tailored  to  the  unique  work  characteristics 
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of  the  MTF  through  the  addition  of  supplemental  attributes. 
(Ref  25) 

Recommendations 

It  is  recommended  that  the  TRIMIS  office  support  WPAFB- 
MC  and  AFIT  by  sponsoring  a  follow  on  team  (2)  thesis  that 
would  develop  a  Laboratory  -  Pharmacy  Module  and  an  Account¬ 
ing  -  Logistics  Module.  It  is  suggested  that  at  least  one 
team  member  have  DBA  experience  and  both  members  have  course 
work  in  EE  6H6  -  Computer  Database  Systems  and  MA  7^6  - 
Advanced  Database  Management  Systems.  In  addition,  as  each 
module  is  built  it  should  be  implemented  and  run  parallel 
with  existing  TRIMIS  programs.  This  will  allow  for  eval¬ 
uation  of  the  effectiveness  of  a  relational  data  base. 

Since  the  TRIMIS  office  was  unable  to  provide  inputs  as 
to  the  type  of  DBMS  they  would  prefer  (this  is  due  to  confi¬ 
dentiality  rules  governing  ongoing  contract  negotiations) 
and  the  lack  of  commonality  of  hardware,  no  recommendations 
are  made  as  to  type  of  existing  DBMS  to  use.  However,  it  is 
strongly  suggested  that  a  currently  existing  commercial 
system  be  used  rather  than  in  house  development. 

Final  recommendations  are:  that  AFIT  and  TRIMIS  estab¬ 
lish  closer  ties.  TRIMIS  should  upgrade  some  of  their  51XX 
slots  to  masters’  level,  and  task  the  Military  Personnel 
Center  (MPC)  for  AFIT  inputs.  This  approach  would  provide 
the  expertise  in  computers  that  is  essential  to  TRIMIS 
effectively  meeting  its  goals. 


VI-2 


Summary 

The  intent  of  this  thesis  was  to  develop  a  detailed 
method  for  specifying,  implementing  and  demonstrating  a 
conceptual  model  of  the  administrative  portion  of  WPAFB-MC. 
It  has  accomplished  that  end.  The  schema’s  design  has  been 
developed  in  a  style  that  can  be  generalized  to  other  areas 
of  the  hospital  so  as  to  cultivate  a  total  hospital  informa¬ 
tion  system.  The  challenge  that  remains  is  to  complete  the 
process . 
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Appendix  A 


MANAGEMENT/ADMINISTRATION 

1.  Analyze  existing  information  systems  (-485). 

2.  Appoint  DBMS  project  officer  (-485). 

3.  Develop  general  mission  guidelines  (-455). 

4.  Appoint  hospital  data  base  manager  (-425). 

5.  Begin  hospital  data  base  conversion  (—330). 

6.  Establish  liaison  with  local  DPI  management  (-300). 

7.  Collect  cost  benefit  analysis  baseline  data  (pre-imple¬ 
mentation)  (-l80). 

8.  Develop  acceptance  test  plan  (-150). 

9.  Develop  cost  benefit  analysis  measurement  criteria 

(-150). 

10.  Determine  if  acquired  documentator  is  adequate  (-120). 

11.  Develop  parallel  operation/fallback  posture  (-120). 

12.  Prepare  disaster/emergency/fire/safet.v  plans  (-90). 

13.  Develop  data  securitv/privacy/medi cal  ethics  policy 
(-90). 

14.  Prepare  operations  schedule  and  product  control/distri¬ 
bution  plan  (-90). 

15.  Prepare  initial  operating  instructions  (-60). 

16.  Review  of  acceptance  test  plan  with  vendor  (-60). 

17.  Perform  hospital  DBMS  verification  in  simulated  mode 

(-60). 

18.  Develop  recovery  storage  procedure  (-45). 

19.  Develop  discipline  for  receipt  of  software  changes 

(-45). 

20.  Arrange  Principal  Period  of  Maintenance/Preventive  Main¬ 
tenance/Remedial  Maintenance  Schedules  and  specify 
problem  reporting  channels  (-45). 


21.  Arrange  fire/safety  inspection  (-30). 

22.  Establish  master  contacts  roster  (-30). 

23.  Specify  acceptance  test  meeting  schedule  and  format 
(-30). 

2k.  Hardware  installation  (~30). 

25-  Hardware  integration  (-10).  * 

26.  Software  integration  (-10). 

27.  Begin  acceptance  test  (D-Day). 

28.  Functional  validation  (+10). 

29.  Hardware  certification  (+30).  * 

30.  Software  certification  (+30). 

31.  Collect  baseline  data  (post-imDlementation )  (  +  120). 

32.  Cost  benefit  analysis  (begin  Phase  I)  (+l8o). 

* (The  references  to  hardware  need  only  apply  if  new  equip¬ 
ment  is  necessary  to  implement  DBMS  or  if  none  exists.) 
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IMPLEMENTATION  SCHEDULE 
of 

MANAGEMENT/ADMINISTRATION 


A.l.  Analyze  existing  data  jase  information  system. 

Analyze  existing  hospital  procedures  to  determine 
their  inter  and  intra  information  reauests.  Estab¬ 
lish  objectives  to  be  achieved  by  a  DBMS  at  the  fa¬ 
cility  . 

A .2.  Appoint  DBMS  project  officer. 

The  commander  of  the  Medical  Treatment  Facility  (MTF) 
should  appoint  a  project  officer  who  will  be  respon¬ 
sible  for  implementing  the  DBMS.  This  project  officer 
should  be  drawn  from  the  command/administrative  sec¬ 
tion  or  more  ideally  from  a  Medical  Computer  Systems 
Office  if  one  exists  within  the  MTF.  He/She  shall 
serve  as  the  single  point  of  contact  to  initiate 
actions  and  resolve  problems  associated  with  the  im¬ 
plementation.  The  project  officer  must  have  full 
commitment  from  both  the  command  section  and  hospital 
sections  management  t.o  make  timely  system  development 
schema  changes. 

A. 3.  Develop  general  mission  guidelines. 

Determine  whether  there  will  be  any  mission  changes  of 
offices  associated  with  the  DBMS  in  its  development. 
Develop  Implementation  plan.  Develop  a  specific  imple¬ 
mentation  plan  for  your  MTF  using  this  document  as  a 
guideline. 


A.fJ.  Appoint  DBMS  manager. 

Appoint  a  person  in  the  computer  center  who  will  be 
responsible  for  creating  and  maintaining  the  hospital 
DBMS.  The  skills  of  the  person  selected  should  be 
primarily  administrative/clinical  with  a  working  know¬ 
ledge  of  DBMS  systems.  Plan  to  involve  all  users 
inoperational  training  as  early  as  possible. 

A. 5.  Begin  hospital  data  base  identification. 

Gather  information  concerning  tests,  workload,  re¬ 
ports,  and  etc.,  so  that  all  appropriate  views  of  data 
can  be  developed  for  the  new  system.  This  information 
must  be  put  into  at  least  3NF. 


A-3 


A. 6.  Establish  liaison  with  local  DPI  management. 


Establish  a  good  working  relationship  with  local  Data 
Processing  Installations  (DPI).  Their  experience  and 
background  may  save  costly  planning  errors  in  your 
local  schema  design. 

A. 7.  Collect  cost  benefit  analysis  baseline  data  (pre- 
implementation  ) . 

This  normally  done  by  either  a  consulting  firm  or  the 
local  Management  Engineering  Team.  The  purpose  of 
this  study  is  to  provide  an  effective  picture  of  the 
existing  hospital  operations  prior  to  DBMS  implemen¬ 
tation  . 

A. 8.  Develop  acceptance  test  plan. 

Develop  a  plan  to  "accept”  the  DBMS.  An  acceptance 
test  verifies  that  the  hardware  and  software  are  ac¬ 
ceptable  to  the  MTF.  The  military  services  have 
specific  requirements  for  conducting  an  acceptance 
test.  Your  DPI  liaison  should  be  able  to  assist  in 
preparing  this  plan.  Particular  emphasis  should  be 
placed  on  devising  the  record  format  for  tracking  of 
acceptance  test  time  elements  as  well  as  clearly  de¬ 
fining  those  time  elements  from  logical,  regulatory 
and  contractual  guidelines.  A  key  question  for  de¬ 
termining  downtime  will  be,  "Is  the  Government’s  nor¬ 
mal  schedule  of  useful  work  impaired  by  software  or 
hardware  downtime?".  Objective  should  be  clarity  and 
completeness  of  definitions  and  rules  during  accep¬ 
tance  test  phase. 

A. 9-  Develop  cost  benefit  analysis  measurement  criteria. 

Based  upon  the  objectives  established  in  event  A.I., 
determine  how  the  achieving  of  these  objectives  (e.g., 
faster  turnaround  of  test  information)  can  be  mea¬ 
sured.  It  is  important  to  remember  that  varying  or 
inconsistent  management  policies  during  system  imple¬ 
mentation  can  cause  erroneous  interpretations  of 
measurements  or  unwittingly  change  parameters. 

A. 10.  Determine  if  acquired  documentation  is  adequate. 

Evaluate  documentation  needs  (e.g.,  software,  system 
and  operations  manuals)  to  assure  supply  on  hand  meets 
functional  requirements. 

A. 11.  Develop  parallel  operation/fallback  posture. 

As  part  of  the  acceptance  test,  parallel  operations 
should  be  undertaken  until  a  sufficient  level  of  con- 
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fidence  is  achieved.  Also,  a  fallback  posture  must  be 
developed  in  case  of  a  catastrophic  failure  during 
implementation . 

A. 12.  Prepare  disaster/emergency/f ire/safety  plans. 

Prepare  plans  required  by  regulation  in  conjunction 
with  appropriate  offices.  The  plan  should  include 
provisions  for  training  of  affected  personnel. 

A. 13.  Develop  data  security/privacy/medical  ethics  policy. 

After  reviewing  appropriate  regulations  develop  a 
written  policy  on  these  matters.  Consider  distribu¬ 
tion,  disposition  and  destruction  of  records. 

A. 14.  Prepare  operations  schedule  and  product  control/dis¬ 
tribution  plan. 

In  conjunction  with  the  functional  departments  prepare 
an  operations  schedule  consistent  with  processing  and 
report  needs.  Prepare  product  distribution  plan  con¬ 
sidering  breakdown  and  mailing  conventions.  Utilize 
self  pick  up  where  possible  to  reduce  manpower  needs 
but  avoid  unofficial  access  to  reports. 

A. 15.  Prepare  initial  operating  instructions. 

Prepare  operating  instructions  that  support  all  de¬ 
tailed  aspects  of  the  DBMS  implementation. 

A. 16.  Review  of  acceptance  test  plan  with  vendor. 

Review  plan  developed  in  event  A. 8  with  vendor  so  that 
he  knows  what  type  of  test  and  the  "ground  rules"  of 
the  test  that  will  be  conducted. 

A. 17.  Perform  DBMS  verification  in  simulated  mode. 

"Desk  check"  the  DBMS  to  insure  the  quality  of  the 
information  and  reduce  error  correction  once  the 
acceptance  test  begins. 

A. 18.  Develop  redundant  storage  procedure. 

Develop  procedure  and  places  for  storing  "copies”  of 
the  data  base.  These  should  be  outside  the  computer 
room  in  a  controlled  environment  offsite,  that  is,  in 
another  building  storage  should  also  be  allocated.  A 
good  place  for  off-site  storage  would  be  the  base  DPI. 
Another  redundancy  consideration  is  archival  search  to 
secure  individual  patient  histories  or  epidemiological 
data. 


A. 39.  Develop  discipline  for  receipt  of  software  changes. 

A  method  should  be  developed  for  reporting  problems 
and  receiving  software  changes  from  the  vendor.  This 
procedure  will  allow  the  MTF  to  monitor  changes  and 
vendor  responsiveness  to  software  problems.  This  plan 
must  have  vendor  coordination.  Modifications  should 
consist  of  the  following  entities: 

a.  System  change  number. 

b.  Type  of  change. 

c.  Purpose  and  description  of  change. 

d.  Narrative  of  problems  resolved  (specifying 
dump  numbers  if  appropriate). 

e.  Method  of  implementation  and  instruction. 

f.  Identity  of  programs,  files,  inputs  or  outputs 
affected  and  how. 

g.  Discussion  of  operational,  functional  and 
management  procedures  affected. 

h.  Jopies  of  new  and/or  amended  documentation. 

i.  List  of  attachments. 

j.  Additional  information  comments. 


A. 20.  Arrange  Principal  Period  of  Maintenance/Preventive 
Maintenance/Remedial  Maintenance  Schedules  and  specify 
problem  reporting  channels. 

The  range  of  hours  will  be  set  during  contract  nego¬ 
tiations.  The  MTF  will  select  the  specific  hours  for 
each  maintenance  category  with  thelocal  vendor  repre¬ 
sentative.  For  detailed  explanation  of  these  terms 
refer  to  your  specific  contract. 

A. 21.  Arrange  fire/safety  inspection. 

The  computer  room  site  must  be  inspected  by  the  fire 
and  safety  officials  prior  to  acceptance  test. 

A. 22.  Establish  master  contacts  roster. 

Establish  a  list  of  all  MTF,  vendor,  and  DPI  personnel 
who  should  be  contacted  if  a  problem  occurs.  Also 
determine  the  correct  procedure  for  use  of  this  roster 
(i.e.,  who  should  call  whom  on  the  problem). 


A. 23-  Specify  acceptance  test  meeting  schedule  and  format. 

The  acceptance  test  procedure  is  a  formal  methodology 
for  the  Air  Force  to  accept  a  system.  The  acceptance 
test  meetingis  part  of  the  procedure,  therefore  all 
system  problems  should  be  documented  in  the  minutes 
of  these  meetings.  Assure  full  representation  by 
responsible  entities  as  the  meeting  will  frequently 
provide  the  medium  for  assigning  tasks  to  resolve 
problems . 

A.2H.  Hardware  installation. 

Equipment  should  be  installed  by  the  vendor. 

A. 25.  Hardware  integration. 

Is  the  system  installed  and  working  properly.  Closely 
monitor  vendor  diagnostic  activity  and  use  of  main 
peripheral  devices. 


A. 26.  Software  integration. 

Vendor  wil  load  and  integrate  software  after  the  hard¬ 
ware  is  operational.  Again  monitor  vendor  diagnostic 
activity. 

A. 27.  Begin  acceptance  test. 

Implement  acceptance  test  plan. 

A. 28.  Functional  validation. 

Taking  each  department  or  functional  query,  separately 
validate  data  entered  and  reported  to  insure  validity. 
Functional  validation  will  insure  that  the  DBMS  meets 
the  requirements  set  forth  in  the  Department  of  De¬ 
fense  documentation. 

A. 29.  Hardware  certification. 

Hardware  malfunctions  and  repair  will  accrue  downtime 
which  will  enter  Into  the  effectiveness  level  compu¬ 
tation  maintained  by  the  DPI.  Hardware  downtime  will 
be  substantiated  on  the  approptiate  form.  Hardware 
downtime  records  must  be  maintained  on  a  component  as 
well  as  system  basis.  The  hardware  will  be  certified 
once  the  contractual  effectiveness  level  is  reached. 

A. 30.  Software  certification. 


The  performance  of  the  systems  functional  tests  will 
be  reviewed.  If  the  performance  standards  set  forth 


for  acceptance  testing  are  met,  the  software  will  be 
certified  as  acceptable.  The  certification  with  sup¬ 
porting  documentation  will  be  provided  to  the  Equip¬ 
ment  Control  Officer  of  the  DPI  by  the  project  direc¬ 
tor  . 

A. 31.  Collect  baseline  data  (postimplementation). 

The  local  Management  Engineering  Team  collects  this 
information . 

A. 32.  Cost  benefit  Analysis  (begin  Phase  I). 

The  local  Management  Engineering  Team  should  perform 
this  function. 


A-8 


Appendix  B 


FUNDING/BUDGET 


1.  Submit  budget  request  for  construction,  supplies,  equip¬ 
ment,  utilities,  rental  and  purchase  of  ADPE,  as  appropriate 
(365). 

2.  Assure  budget  requirements  have  been  met  (270). 


FUNDING /BUDGET 


B.l.  Submit  budget  requeest  for  construction,  supplies, 
equipment,  utilities  and  rental/purchase  of  ADPE,  as 
appropriate. 

Computer  systems  in  the  Department  of  Defense  are 
covered  by  specific  regulations.  The  MTF  will  have  to 
be  familiar  with  these  regulations  and  how  to  submit 
budget  requests,  in  order  to  submit  the  proper  paper¬ 
work.  Be  sure  to  consider  budgetary  projections  for 
the  various  desks,  tables,  chairs,  and  cabinetry  as¬ 
sociated  with  any  new  functional  activity. 

B.2.  Assure  budget  requirements  have  been  met. 

Since  computer  system  in  a  hospital  will  not  follow 
"normal"  established  procedures,  the  project  officer 
must  follow-up  on  all  budget  requests  to  insure  ade¬ 
quate  explanation  of  all  paperwork  is  provided.  Fur¬ 
ther  he/she  should  monitor  approval  channels  to  obtain 
reasonable  assurance  that  funds  will  be  available  when 
required . 
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Appendix  C 
SUPPLIES/EQUIPMENT 

1.  Appoint  supply  monitor  (-395). 

2.  Identify  supply  needs  (-365). 

3.  Establish  availability  and  source  for  needed  supplies 
(-330). 

ij.  Order  supplies  (-270). 

5.  Order  needed  desks,  tables,  shelves,  chairs,  racks,  etc., 
as  required  for  central  and  remote  site  locations  (-270). 

6.  Assure  adequate  supplies  and  equipment  are  on  hand  (-90). 

7.  Establish  supply  levels  and  reorder  points  (+90). 
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SUPPLIES/EQUIPMENT 


C.l.  Appoint  supply  monitor. 

Self-explanatory.  The  supply  monitor  ideally  should 
be  the  person  normally  associated  with  providing  sup¬ 
plies  to  the  MTF. 

C.2.  Identify  supply  needs. 

Vendor,  other  DBMS  users,  and  DPI  personnel  should  be 
able  to  assist  the  supply  monitor  in  establishing  his 
supply  needs. 

C.3*  Establish  availability  and  source  for  needed  supplies. 

Some  of  the  supplies  (e.g.,  stock  paper)  can  be  or¬ 
dered  from  base  supply  channels;  other  (e.g.,  test 
request  cards)  will  have  to  be  ordered  from  special 
sources.  Identify  these  sources  and  necessary  lead 
times  for  ordering. 

C.4.  Order  supplies. 

Self-explanatory. 

C.5.  Order  needed  desks,  tables,  shelves,  chairs,  racks, 
etc.,  for  central  site  and  remote  locations. 

The  project  officer  should  determine  what  office 
equipment  is  required  for  the  computer  room.  This 
applies  if  a  redesign  of  existing  facilities  is 
needed.  Each  potential  remote  location  (outside  com¬ 
puter  room)  should  also  be  examined  to  Insure  that  the 
equipment  ordered  for  that  location  can  be  placed  in 
an  easily  accessible  area. 

C.6.  Assure  adequate  supplies  and  equipment  are  on  hand. 

Adequate  follow-up  procedures  must  be  established  to 
assure  timely  delivery  of  supplies  and  equipment. 

C.7.  Establish  supply  levels  and  reorder  points. 

After  sufficient  supply  history  has  been  maintained, 
establish  reorder  points  for  all  items. 
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EDUCATION 

1.  Provide  executive  level  briefings  at  30  dav  intervals 
M55) 

2.  Refresher  training  for  DP  personnel  in  data  base  design 
for  conversion  work  (“365). 

3.  Determine  availability  of  vendor  or  Department  of  De¬ 
fense  training  support  (-l8o). 

1|.  Establish  training  requirements  (-150). 

5.  Provide  middle  management  briefings  (-120). 

6.  Provide  executive  level  briefing  on  acceptance  test 

(-120). 

7.  Prepare  operator/technician  training  plans  (-90). 

8.  Begin  operator/technician  training  (-30). 

9.  Begin  product  user  training  (-30). 

10.  Provide  acceptance  test  briefing  to  middle  management 
and  technicians  (-15). 

11.  Provide  post-acceptance  test  briefing  to  middle  manage¬ 
ment  and  technicians  (+60). 
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EDUCATION 


D.l.  Provide  executive  level  briefings  at  30  day  intervals. 

Top  management  support  is  a  requirement  to  success¬ 
fully  implement  the  DBMS.  These  meetings  should  be 
used  to  keep  top  management  informed  and  solicit  their 
support.  A  sincere  and  well  managed  investment  in 
orientation,  acclimation  and  training  of  the  staff 
(OATS)  will  yield  a  significant  return  in  terms  of 
system  efficiency  and  staff  acceptance. 

D.2.  Train  DP  personnel  in  data  base  implementation  tech¬ 
niques  . 

This  training  will  be  accomplished  by  either-  the  ven¬ 
dor,  TPO  or  other  hospital  sites. 

D.3.  Determine  availability  of  vendor  or  Department  of 
Defense  training  support. 

This  training  will  be  specified  by  the  contract  in  the 
case  of  the  vendor.  The  TRIM1S  Program  Office  will 
have  a  training  plan  for  each  hospital  site.  For 
repetitive  training  modules  such  as  those  for  tech¬ 
nicians,  Investigate  the  possibility  of  using  com¬ 
puter-assisted  instruction  (CAI)  capabilities. 

D.*4.  Establish  training  requirements. 

Identify  all  personnel  who  are  to  be  trained  and  the 
type  of  training  required. 

D.5.  Provide  middle  management  briefings. 

In  order  to  gather  support  for  system  implementation, 
provide  periodic  briefings  to  middle  management  on 
what  DBMS  Is  and  what  benefits  the  system  will  pro¬ 
vide.  Hospital  personnel  must  be  continually  kept  up- 
to-date  by  required  attendance  briefings  and  by  assis¬ 
tance  visits.  A  user’s  guide  for  the  health  care 
provider  should  be  prepared  as  soon  as  an  operating 
protocol  is  developed. 

D.6.  Provide  executive  level  briefing  on  acceptance  test. 

Provide  top  management  with  an  overview  of  the  ac¬ 
ceptance  process  along  with  the  expected  objectives  to 
be  accomplished  during  the  test. 

D.7.  Prepare  operator/technician  training  plans. 

Prepare  detailed  plans  to  accomplish  both  computer 
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vendor  training,  although  a  beginning,  often  lacks  the 
essential  references  and  examples  that  hospital  per¬ 
sonnel  need  to  orient  the  presentation  to  the  actual 
task  at  hand. 

D.8.  Begin  operator/technician  training. 

Self-explanatory . 

D.Q.  Begin  product  user  training. 

Self-explanatory . 

D.10.  Provide  acceptance  test  briefing  to  middle  management 
technicians . 

Prepare  management  and  technicians  for  acceptance  test 
by  using  briefing  devt loped  in  event  D.6. 

D.ll.  Provide  post-acceptance  test  briefing  to  middle  man¬ 
agement  and  technicians. 

Provide  information  regarding  status  of  system  and 
lessons  learned  during  acceptance  test.  Emphasise  how 
cooperative  efforts  have  led  to  current  stage  of 
progress . 
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PERSONNEL/MANPOWER 


1.  Ascertain  manpower  needs  and  type  (i.e.,  civilian  or  mil 
itary)  (-425). 

2.  Submit  manpower  requests  (-365). 

3.  Obtain  confirmation  of  manpower  allocation  (-180). 

4.  Prepare  position  descriptions  for  new  civilian  job  re 
quirements  (-180). 

5.  New  personnel  to  report  (-45). 
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PERSONNEL/MANPOWER 


E.l.  Ascertain  manpower  needs  and  types  (i.e.,  civilian  or 
military) . 

Determine  what  the  manpower  requirements  are  for  DBMS. 
Other  DBMS  users  will  be  a  good  source  of  information 
on  this  topic.  Also  determine  the  mix  of  the  required 
personnel  (refer  to  Chapter  5). 

E.2.  Submit  manpower  requests. 

Self-explanatory. 

E.3.  Obtain  confirmation  of  manpower  allocation. 

Monitor  manpower  requests. 

E.Jj.  Prepare  position  descriptions  for  new  civilian  job  re¬ 
quirements. 

Self-explanatory . 

E.5.  New  personnel  to  report. 

Self-explanatory . 
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FACILITIES/COMMUNICATIONS 


1.  Establish  management  plan  for  system  layout  (-H25). 

2.  Obtain  site  specifications  if  any  from  computer  vendor 
(-395). 

3.  Consider  emergency  backup  power  and  air  conditioning 
installation  (-395). 

H.  Submit  request  for  site  design  to  CE  (-365). 

5.  Begin  Civil  Engineering  design  (-330). 

6.  Solicit  site  preparation  bids  (-270). 

7.  Establish  necessary  work  and  storage  areas  (-270). 

8.  Award  site  preparation  contract  (-180). 

9.  Review  design  layout  for  efficiency,  accessibility  and 
human  engineering  (-180). 

10.  Submit  requests  for  communicatons  lines  (-150). 

11.  Secure  calibrated  hydro-thermagraphs  for  measurement  of 
critical  environments  (-90). 

12.  Review  equipment  movement  plan  considering  door  size, 
hallways,  turns,  elevators,  ramps,  docks  and  floor  sup¬ 
ports  (-90). 

13.  Make  final  inspection  of  site  environment (-45 ) • 
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FACILITIES/COMMUNICATIONS 


F.l.  Establish  management  plan  for  system  layout. 

Develop  plan  for  system  (e.g.,  communication  networks) 
layout.  Determine  where  the  system  will  be  located 
and  what  impact  the  location  will  have  on  the  existing 
work  and  information  flow.  Where  peripheral  devices 
are  located  is  important  for  ease  of  access,  protec¬ 
tion  of  equipment  and  optimum  utilization. 

F.2.  Obtain  site  specifications  from  computer  vendor. 

These  specifications  will  detail  the  power  require¬ 
ments  and  access  space  around  the  computer  equipment. 
This  information  will  be  needed  by  Civil  Engineering 
to  design  any  special  remote  sites.  Other 
environmental  considerations  will  include  such  things 
as  temperature  and  humidity  ranges  for  operation, 
susceptibility  to  power  fluctuations,  physical  size 
and  weight  of  devices,  heat  generation,  noise  genera¬ 
tion,  safety  factors. 

F.3.  Consider  emergency  backup  power  and  air  conditioning 
installation. 

If  at  all  possible  the  computer  room  should  be  pro¬ 
vided  with  a  backup  power  source  in  case  of  a  power 
failure  and  backup  air  conditioning  In  case  of  air 
conditioning  failure.  This  will  allow  for  continuous 
operaton . 

F.t.  Submit  request  for  site  design  to  Civil  Engineering. 

While  the  Base  CE  will  design  areas,  they  will  be 
looking  to  the  MTF  to  provide  quidelines  so  that  the 
work  flow  will  proceed  smoothly.  Event  F.l.  should 
provide  guidelines. 


F.5.  Begin  Civil  Engineering  design. 

Self-explanatory . 

F.6.  Solicit  site  preparation  bids. 

This  will  be  done  by  Base  Procurement. 

F.7.  Establish  necessary  work  and  storage  areas. 

The  site  design  should  include  a  small  storage  area  in 
the  computer  room  and  a  larger  area  in  the  immediate 
vicinity  of  the  room  for  storage  of  tapes,  disks  and 
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supplies.  Also  areas  must  be  allocated  for  records 
and  redundant  storage.  A  system  analyst  work  area 
should  preferably  be  proximal  to  the  computer  area  and 
data  base  management  area.  An  operator’s  break  area 
near  the  computer  room  will  accommodate  operators  on 
break  or  at  lunch  and  will  usually  satisfy  union 
demands . 

F.8.  Award  site  preparation  contract. 

Base  Procurement  will  do  this  function. 

P.9.  Review  design  layout  for  efficiency,  accessibility 
and  human  engineering. 

This  is  the  final  chance  to  review  the  design  prior  to 
construction.  Remember  that  human  engineering  in¬ 
cludes  the  objective  of  making  tasks  as  pleasant  and 
convenient  as  possible. 

F.10.  Submit  request  for  communication  lines. 

This  request  is  for  phone  lines  that  will  connect  the 
computer  and  the  terminals  in  the  remote  areas.  This 
base  Communication  Group  will  need  the  Information 
that  is  supplied  by  the  vendor  on  type  of  service  the 
system  requires.  Do  not  forget  to  consider  any 
additional  human  to  human  communication  needs. 

F.ll.  Secure  calibrated  hydro-thermagraphs  for  measurement 
of  computer  room  environment. 

These  instruments  can  be  obtained  through  the  GSA 
catalogue.  One  is  required  in  all  computer  rooms. 
Vendors  are  historically  hypercltlcal  of  operating  en¬ 
vironments.  Maintain  spare  devices  in  case  the  pri¬ 
mary  hydro-thermagraph(s )  are  suspected  to  be  inac¬ 
curate. 

F.12.  Review  equipment  movement  plan  considering  door  size, 
hallways,  turn,  elevators,  ramps,  docks  and  floor 
support. 

Self-explanatory . 

F.13.  Make  final  inspection  of  site  environment. 

Self-explanatory . 
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Appendix  G 
DATA  DICTIONARY 


SYMBOL 

ABSENT :STAT 

A  DDR 

ADMIT: DATE 

ADMIT :DI AG 

ADMIT: PHY 

ADMIT :STAT 

ADMIT  .-STATUS 
ADS  CD 

AERO:RTNG 

ARVL:TM 

ATND.-PHY 

AVAIL: BED 


DESCRIPTION 


SIZE 


INPATIENT  ABSENT  STATUS  2 
WHICH  IS  DETERMINED  BY 
ADMISSION  TYPE  OP  CARE 
BEING  RENDERED  OUTSIDE 
MILITARY  MEDICAL  FACILITY 

HOUSE  NUMBER,  STREET  NAME  30 
4  APT  NO. 


DATE  ADMITTED  TO  ORIGINAL  6 
MTF  ( DDMMYY ) 


CODED  INITIAL  DIAGNOSIS  7 

FOR  DISORDER  THAT  NECES¬ 
SITATED  ADMISSION  TO  MTF 

PHYSICIAN  WHO  AUTHORIZES  9 

ADMISSION  (USE  PROV# ) 

STATUS  OF  ADMISSION:  CAN  1 
CEL  OR  NEW  DENOTED  BY: 

C/N 

ADMISSION  STATUS  h 

ACTIVE  DUTY  SERVICE  COM-  7 

MITMENT  DATE  ( DDMMYY ) 

AERONAUTICAL  RATING  (Y/N)  1 

ARRIVAL  TIME  THAT  PATIENT  5 

ANNOUNCES  PRESENCE  IN 
CLINIC  RECORD  IN  MILITARY 
FORMAT  (EX:  13:08) 

ATTENDING  PHYSICIAN  AS-  9 

SIGNED  TO  CASE  (USE  PROV#) 

TOTAL  NUMBER  OF  UNASSIGN-  3 

ED  BEDS  AVAILABLE  ON  THE 
WARD 


VIEWS 

ABSENT 


EMERGENCY 

MEDICAL 

INSTITUTION 

PATIENT 

REGISTRATION 

SPONSOR 

TRANSFER 

ADMISSION 

ADMISSION 

ADMINISTRATIVE 

DISPOSITION 

ADMINISTRATIVE 

PERSONNEL 

REGISTRATION 

APPOINTMENT 

ADMINISTRATIVE 

BED  STATUS 
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BED: DYS 

CUMULATIVE  TOTAL  OF  BED 
DAYS  OCCUPIED  BY  PATIENTS 
(RESET  TO  ZERO  MONTHLY) 

4 

WARD 

BED* 

UNIQUE  NUMBER  ASSIGNED  TO 

A  BED 

4 

BED  STATUS 

BENE: TYPE 

BENEFICIARY  TYPE  SUCH  AS 
ARMY,  NAVY,  AIR  FORCE 

2 

PATIENT 

BLCK-.BED 

TOTAL  NUMBER  OF  BEDS  EI¬ 
THER  IN  USE  OR  TEMP- 

PORARILY  MARKED  UNAVAIL¬ 
ABLE 

3 

BED  STATUS 

CASUALTY# 

ANY  NON  VIRAL  OR  BACTER¬ 
IAL  ILLNESS  DENOTED  BY  A 
NUMERIC  IDENTIFIER 

3 

ADMISSION 

CITY 

NAME  OF  CITY  IN  WHICH 
PATIENT  LIVES  (PATIENT’S, 
PRIMARY  CONTACT  IN  EMER¬ 
GENCY,  SPONSOR,  ETC. 

20 

EMERGENCY 

MEDICAL 

INSTITUTION 

REGISTRATION 

SPONSOR 

CIV:MTF 

CIVILIAN  HOSPITAL  THAT 
INPATIENT  IS  LOCATED  IN 

27 

ABSENT 

CLERK 

THE  CLERK’S  INITIALS 

3 

ADMISSION 

DISPOSITION 

CLINIC# 

UNIQUE  CLINIC  IDENTIFICA¬ 
TION  NUMBER 

2 

APPOINTMENT 

CLINIC 

HOLIDAYS 

PROVIDER-CLINIC 

CLINIC :SVC 

MNEMONIC  FOR  CLINIC  SPE¬ 
CIALTIES  AVAILABLE  (EX: 
bbGYN ) 

5 

ADMINISTRATIVE 

COMND: 

INTRST 

PARENT  COMMAND  OF  PATIENT 

OR  SPONSOR  (MAC , SAC ,TAC , 

ETC .  ) 

3 

SPONSOR 

CPR:TRNG: 

CODE 

CODE  REPRESENTING  CURRENT 
CPR  SKILL  LEVEL  (TABLE 
NOT  MADE  YET) 

3 

PERSONNEL 

C  PR -.DATE 

DATE  CPR  TRAINING  COM¬ 
PLETED  (DDMMYY) 

6 

PERSONNEL 

CUR: AIR: IN 

TOTAL  AIR  EVAC  PATIENTS 

IN  THAT  DAY 

3 

WARD 

CUR: AIR: OUT 

TOTAL  AIR  EVAC  PATIENTS 
OUT  THAT  DAY 

3 

WARD 

CUR: AIR 

TOTAL  NUMBER  OF  AIR  EVAC 
PATIENTS  CURRENTLY  ON  THE 
WARD 

3 

WARD 

CUR: REG I ST: NO 

CURRENT  INPATIENT  REGIS¬ 
TER  NUMBER  ASSIGNED  BASED 

ON  DATE  AND  TIME  OF  AD¬ 
MISSION  TO  MTF 

6 

HISTORY 

DAPSC 

DUTY  AIR  FORCE  SPECIALTY 
CODE 

5 

PERSONNEL 

DAS 

DATE  OF  ACTIVE  SERVICE 
( DDMMMYY ) 

7 

PERSONNEL 

DATE 

CURRENT  DATE 

6 

ADMISSION 

APPOINTMENT 

CASUALTY 

HISTORY 

DATE: 

ASIGN 

DATE  PHYSICIAN  ASSIGNED 

TO  CASE  (DDMMYY ) 

6 

ADMINISTRATIVE 

DATE : CHG 

DATE  CHANGE  IN  STATUS  OF 
PATIENT  CARE,  DIAGNOSIS, 
ETC.  (DDMMYY) 

6 

CASUALTY 

DATE: CLSD 

DATES  THE  WORK  AREA  IS 
CLOSED  (DDMMYY) 

6 

HOLIDAYS 

DATE : CNX 

DATE  OF  ACTUAL  CANCELLA¬ 
TION  OF  ADMISSION  (DDMMYY) 

6 

ADMISSION 

DATE : CONFMD 

DATE  THE  INDIVIDUAL  BE¬ 
CAME  A  CONFIRMED  MEB  CAN¬ 
DIDATE  (DDMMYY) 

6 

MED  BOARD 

DATE: DISPO 

DATE  OF  DISCHARGE  (DDMMYY) 

6 

DISPOSITION 

DATE: I DENT 

DATE  THE  INDIVIDUAL  WAS 
IDENTIFIED  AS  A  POTENTIAL 
MEB  CANDIDATE  (DDMMYY) 

6 

MED  BOARD 

DATE: INACT: 
STATUS 

ACTIVE  OR  INACTIVE  STATUS 
DATE  CHANGE  (DDMMYY) 

6 

HISTORY 

DATE:KIN:NTFY 

DATE  NEXT  OF  KIN  NOTIFIED 
(DDMMYY) 

6 

CASUALTY 

0-3 


DATE : RESOLV 

DATE  THAT  THE  MEB  RE¬ 
SOLVED  THE  INDIVIDUAL’S 
CASE  ( DDMMYY ) 

6 

MED  BOARD 

DATE :RTRN: TIME 

RETURN  TIME  AND  DATE 

(DDMMYYbl3:08) 

IP 

ABSENT 

DATE.-RMVD 

DATE  REMOVED  FROM  CASUAL¬ 
TY  ROSTER  (DDMMYY) 

6 

CASUALTY 

DATE: SVC 

DATE  SERVICE  ASSIGNED 
(DDMMYY) 

6 

ADMINISTRATIVE 

DAY :  PH 

PATIENT’S  BUSINESS  PHONE 
(XXXYYYZZZZ ) 

10 

REGISTRATION 

DEP:CODE 

CODE  ID  FOR  RELATIONSHIP 

TO  SPONSOR  (TABLE  NOT 

AVAILABLE  YET) 

2 

ABSENT 

ADMISSION 

APPOINTMENT 

CASUALTY 

DISPOSITION 

EMERGENCY 

HISTORY 

MED  BOARD 
PATIENT 
REGISTRATION 
TRANSFER 

DIAGNOSIS 

FREE  TEXT  DIAGNOSIS 

25 

CASUALTY 

DISPO0 

REASON  FOR  AND  TYPE  OF 
DISPOSITION  (TABLE  NOT 
AVAILABLE ) 

DISPOSITION 

DOB 

DATE  OF  BIRTH  (DDMMYY) 

6 

PATIENT 

PERSONNEL 

DOR 

DATE  OF  RANK  (DDMMYY) 

7 

PERSONNEL 

DTY: TITLE 

DUTY  TITLE 

10 

PERSONNEL 

DTY :  PH 

OFFICE  PHONE  (XXXYYYZZZZ) 

10 

PERSONNEL 

EFF: DATE: TIME 

DATE/TIME  THAT  INPATIENT 
ABSENT  STATUS  EFFECTIVE 
(DDMMYYbl3:08) 

12 

ABSENT 

EXPIR:TRM:SVC 

DATE  A  SERVICE  MEMBER  DUE 

TO  BE  RELEASED  FROM  AC¬ 
TIVE  DUTY  (DDMMYY) 

6 

REGISTRATION 

FLY: SVC: CODE 


PATIENT’S  ENTITLMENT  STA¬ 
TUS  (EX:  1  »  PILOT) 


2  REGISTRATION 


FLY  .‘STATUS 

FLIGHT  STATUS  CURRENTLY 

ON  FLIGHT  ORDERS  (Y/N) 

1 

PATIENT 

GAIN  .-DATE 

DATE  PROJECTED  GAIN  TO 
MTF  STAFF  ( DDMMYY ) 

6 

PERSONNEL 

HM:PH 

HOME  TELEPHONE  NUMBER 

(XXXYYYZZZZ ) 

10 

PATIENT 

PERSONNEL 

REGISTRATION 

ID:CD:EXP 

THE  DATE  ID  CARD  EXPIRES 
(DDMMYY) 

6 

REGISTRATION 

INIT: ADMIT 

ORIGINAL  DATE  ADMITTED  TO 
MTF  (DDMMYY) 

6 

TRANSFER 

INSPrDATE 

DATE  ROOM  WAS  INSPECTED 
(DDMMYY) 

6 

ROOMS 

KEY# 

NUMBER  ASSIGNED  TO  KEY 

4 

ROOMS 

SUPERVISOR 

LEGAL :NXT: KIN 

NAME  OF  PERSON  WHO  SHOULD 

BE  NOTIFIED  FIRST  IF  PA¬ 
TIENT  SHOULD  DIE 

30 

EMERGENCY 

LNGTH-.SVC 

TOTAL  AMOUNT  OF  TIME  AC¬ 
CRUED  IN  MILITARY 

3 

REGISTRATION 

LOSS: DATE 

DATE  PROJECTED  FOR  PCS 
OUT  ( DDMMMYY ) 

7 

PERSONNEL 

LV 

ON/OFF  LEAVE  (Y/N)  1  SU¬ 
PERVISOR 

1 

SUPERVISOR 

LST: INPAT: 
DISPO 

DATE  PATIENT  WAS  LAST 

DISCHARED  FROM  THE  MTF 
(DDMMYY) 

6 

HISTORY 

LST: INPAT: 
STATUS 

DATE  PATIENT  WAS  LAST 
ADMITTED  TO  THE  MTF 
(DDMMYY) 

6 

HISTORY 

LST:OUTPAT: 

CLINIC 

DATE  PATIENT  WAS  LAST 
SEEN  BY  APPOINTMENT  AT  AN 
OUTPATIENT  CLINIC  (DDMMYY) 

6 

HISTORY 

LOCK# 

NUMBER  ASSIGNED  TO  A  SPE¬ 
CIFIC  LOCK 

4 

ROOMS 

MARITAL 

STATUS 


PATIENT'S  MARITAL  STATUS 
(M/S/D) 


1  REGISTRATION 


MAX: APNT 

MAXIMUM  APPOINTMENTS  FOR 

A  WORK  AREA  IN  2  k  HR 
PERIOD 

3 

CLINIC 

MEAL: CD 

MEAL  CARD  AUTHORIZED  (Y/N) 

1 

ADMISSION 

MEB: STATUS 

INPATIENT'S  MEDICAL  EVAL¬ 
UATION  BOARD  STATUS  (TA¬ 
BLE  NOT  READY) 

1 

MED  BOARD 
REGISTRATION 

MED:HLD 

IN  HOSPITAL  ATTACHMENT 
UNIT  AND  NOT  OCCUPYING  A 
BED  WITHIN  MTF  (Y/N) 

1 

ADMISSION 

MTF 

NAME  OF  MEDICAL  FACILITY 
CIVILIAN  OR  MILITARY 

30 

MEDICAL  - 
INSTITUTION 

NAME 

NAME  OF:  PATIENT,  DOCTOR, 
ETC. 

30 

PATIENT 

PERSONNEL 

SPONSOR 

NEW: MOD 

A  NEW  CLINICAL  SERVICE 
ASSIGNMENT  OR  MODIFICA¬ 
TION  OF  ERROR  CONCERNING 

AN  INPATIENT  (N/M) 

1 

ADMINISTRATIVE 

NOTIFY: NAME 

NAME  OF  PERSON  TO  CONTACT 

IN  CASE  OF  AN  EMERGENCY 
DOES  NOT  HAVE  TO  BE  A 
NEXT  OF  KIN 

10 

EMERGENCY 

OFC : SYMB 

OFFICE  SYMBOL 

6 

PERSONNEL 

OCCUPY: BED 

TOTAL  NUMBER  OF  BEDS  CUR¬ 
RENTLY  OCCUPIED  BY  INPA¬ 
TIENTS 

3 

BED  STATUS 

OCCUPATION: 

CIV 

NON-MILITARY  OCCUPATION 

25 

REGISTRATION 

OCCUPATION: 

MILITARY 

INDIVIDUAL’S  MILITARY  SPE¬ 
CIALTY  CODE 

5 

REGISTRATION 

ORG : AUTH : ADM 

PERSON  OR  ORGANIZATION 
AUTHORIZING  ADMISSION  TO 
MTF  NORMALLY  A  PHYSICIAN 

30 

ADMISSION 

OTHER 

TOTAL  NUMBER  OF  BEDS  THAT 
ARE  UNAVAILABLE  FOR  REA¬ 
SONS  NOT  LISTED 

3 

BED  STATUS 

PAPC 


PRIMARY  AIR  FORCE  SERVICE 
CODE 


6  PERSONNEL 


PATIENT: CAT 

PATIENT’S  CATEGORY  (EX: 
TESTS,  X-RAY,  ETC.) 

6 

REGISTRATION 

PERM: ACTIVE 

PERMANENT  ACTIVE  DUTY 

1 

REGISTRATION 

PHONE 

PHONE  NUMBER  OF  EMERGENCY 
CONTACT,  LEGAL  NEXT  OF 
KIN,  PHYSICIAN,  ROOM, 
ETC.  (XXX-YYY-ZZZZ) 

lk 

ABSENT 

EMERGENCY 

MEDICAL 

INSTITUTION 

ROOMS 

POS# 

POSITION  NUMBER-AUTHORIZ¬ 
ED  PERSONNEL  SLOTS 

7 

PERSONNEL 

PHY 

NAME  OF  PHYSICIAN 

30 

ABSENT 

PHY : AUTH 

PHYSICIAN  WHO  AUTHENTI¬ 
CATES  DISCHARGE  OF  PA¬ 
TIENT  (USE  PBOV0 ) 

6 

DISPOSITION 

PHY : DISCHG 

PHYSICIAN  ORDERING  DIS¬ 
CHARGE 

9 

DISPOSITION 

PREADMITS 

TOTAL  NUMBER  OP  BEDS 
BEING  HELD  FOR  PREADMIT¬ 
TED  PATIENTS 

3 

BED  STATUS 

PREV : BED: DY 

NUMBER  OF  BEDS  OCCUPIED 

AS  OF  2J4  00-HOURS  ON  THE 
DAY  PREVIOUS  TO  THE  CUR¬ 
RENT  DATE 

k 

WARD 

PREV: BED:  DYS 

TOTAL  NUMBER  OF  BED  DAYS 
PRIOR  TO  TRANSFER  TO  PRE¬ 
SENT  MTF 

3 

TRANSFER 

PREV : CONV : DYS 

TOTAL  NUMBER  OF  CONVALES¬ 
CENT  LEAVE  DAYS  PRIOR  TO 
TRANSFER  TO  PRESENT  MTF 

3 

TRANSFER 

PREV: COOP: DYS 

TOTAL  NUMBER  OF  DAYS  AC¬ 
CRUED  IN  COOPERATIVE  CARE 
PRIOR  TO  A  TRANSFER  TO 
PRESENT  MTF 

3 

TRANSFER 

PREV :QTR: DYS 

TOTAL  NUMBER  OF  DAYS  ON 
QUARTERS  STATUS  PRIOR  TO 
TRANSFER  TO  PRESENT  MTF 

3 

TRANSFER 

PREV :OTHR: DYS 

TOTAL  NUMBER  OF  DAYS  NOT 
OTHER-WISE  DEFINED 

3 

TRANSFER 

PREV:REGIST:NO 

REGISTER  NUMBER  OF  PA¬ 
TIENT'S  MOST  RECENT  INPA¬ 
TIENT  EPISODE 

6 

HISTORY 

PREV:SICK:DYS 

TOTAL  NUMBER  OF  ABSENT 
SICK  DAYS  PRIOR  TO  TRANS¬ 
FER  TO  PRESENT  MTF 

3 

TRANSFER 

PREV:SUP:DYS 

TOTAL  NUMBBR  OF  SUPPLE¬ 
MENTAL  CARE  DAYS  ACCRUED 
PRIOR  TO  TRANSFER  TO  PRE¬ 
SENT  MTF 

3 

TRANSFER 

PRIM: CARE: 
PROVIDER 

PHYSICIAN  WHO  IS  RESPON¬ 
SIBLE  FOR  PRIMARY  CARE 
(USE  PROV# ) 

6 

REGISTRATION 

MTF 

PRIMARY  MEDICAL  FACILITY 
THAT  CARES  FOR  PATIENT 

6 

REGISTRATION 

PRIOR: CODE 

PRIORITY  CODE  ASSIGNED  TO 
MOVE  PATIENT  AHEAD  OF 
OTHERS  DUE  TO  MEDICAL 
NECESSITY  OR  MISSION  NE¬ 
CESSITY 

1 

APPOINTMENT 

PROB 

PROBLEM  CLASSIFICATION  OF 
MEDICAL  ATTENTION  NEEDED 

3 

APPOINTMENT 

PROB:RECVR 

ESTIMATED  RECOVERY  POS¬ 
SIBILITY  OF  PATIENT 

3 

CASUALTY 

PROJ : DISPO 

ANTICIPATED  DATE  OF  DIS¬ 
CHARGE  FROM  INPATIENT 
( DDMMYY ) 

6 

ADMINISTRATIVE 

PROV# 

PROVIDER  NUMBER  REFERS  TO 
PHYSICIAN  UNIQUE  IDENTI¬ 
FICATION  NUMBER  (bbbnnnnnn) 

9 

APPOINTMENT 
PROVIDERS 
PROVIDER  - 
CLINIC 

PROVIDER  - 
SPECIALTY 

RACE 

GENERAL  CLASSIFICATION  OF 
HUMAN  TYPES  (EX:  'C'  - 
CAUCASIAN) 

1 

REGISTRATION 

RANK 

THREE  CHARACTER  CODE  SIG¬ 
NIFYING  RANK  (EX:  2LT) 

3 

PERSONNEL 

SPONSOR 

REC : RQS 

RECORDS  REQUESTED  TO  BE 
PULLED  AND  AT  CLINIC  FOR 
APPOINTMENT  TIME  (Y/N) 

1 

APPOINTMENT 

0-8 


REGISTER: NO 

INPATIENT  REGISTER  NO. 
THAT  IDENTIFIES  PATIENT 
RECORD 

7 

REGISTRATION 

RELATION 

RELATIONSHIP  TO  PATIENT 
(LEGAL  NEXT  OF  KIN,  EMER¬ 
GENCY  CONTACT,  ETC.) 

12 

EMERGENCY 

RELIGION 

RELIGIOUS  PREFERENCE  (EX: 

•l* -HEATHEN) 

1 

REGISTRATION 

RM# 

UNIQUE  NUMBER  ASSIGNED  TO 
ROOM 

il 

ROOMS 

SCHEDlDATE 

DATE  APPOINTMENT  MADE  FOR 
( DDMMYY ) 

6 

TIME  SLOT 

SERVICE 

SPECIFIC  BRANCH  OF  SER¬ 
VICE 

3 

SPONSOR 

SERV : ASGNMT 

DATE  CLINICAL  SERVICE 

ASSIGNED 

7 

ADMINISTRATIVE 

SEX 

GENDER  CLASSIFICATION  (M/F) 

1 

PATIENT 

PERSONNEL 

REGISTRATION 

SOURCE: ADM 

DESCRIPTION  OF  ORIGIN  OF 
ADMISSION  (EX:  ANOTHER 
MTF,  EMERGENCY,  AIR  EVAC, 
ETC.) 

10 

ADMISSION 

SPEC : CODE 

SPECIALTY  CODE  IS  THE 
DECLARED  EXPERT  AREA  (EX: 
NEUROSURGERY) 

3 

PROVIDERS 

SPONSOR: 

NAME 

SPONSOR-NAME  OF  MILITARY 
MEMBER  (LAST,  FIRST,  MI) 

30 

PATIENT 

SSAN 

SOCIAL  SECURITY  NUMBER-A 
UNIQUE  IDENTIFIER 

9 

ABSENT 

ADMISSION 

APPOINTMENT 

CASUALTY 

DISPOSITION 

EMERGENCY 

HISTORY 

MED  BOARD 

PATIENT 

PERSONNEL 

PROVIDERS 

REGISTRATION 

SPONSOR 

SUPERVISOR 

TRANSFER 
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SRVC 

TYPE  OF  MEDICAL  INSTITU¬ 
TION  (EX:  CIV,  MIL) 

3 

MEDICAL  - 
INSTITUTION 

STATE 

ABBREVIATION  OF  STATE 
(PATIENT’S,  PRIMARY  CON¬ 
TACT  IN  EMERGENCY,  SPON¬ 
SOR,  ETC.) 

2 

EMERGENCY 

REGISTRATION 

SPONSOR 

ST: TIME 

START  TIME  FOR  SCHEDULED 
APPOINTMENT  (EX:  13:08) 

H 

APPOINTMENT 
TIME  SLOT 

STATUS : CAS¬ 
UALTY 

CASUALTY  STATUS  (Y/N) 

1 

REGISTRATION 

StpjTIME 

STOP  TIME  FOR  SCHEDULED 
APPOINTMENT  (EX:  13:09) 

il 

APPOINTMENT 

SUPERVISOR: 

SSAN 

SUPERVISOR’S  SOCIAL  SE¬ 
CURITY  NUMBER 

9 

PERSONNEL 

WARD 

TIME 

TIME  OF  ACTUAL  EVENT  IN 
MILITARY  FORMAT  (EX: 
13:08) 

5 

ADMISSION 

DISPOSITION 

TITLE 

TITLE  OF  MEDICAL  UNIT  20 
CLINIC 

20 

CLINIC 

TRANSPR : MTF : 
DATE 

DATE  PATIENT  TRANSFERRED 

TO  ANOTHER  MTF  ( DDMMYY ) 

6 

DISPOSITION 

TAP  DSD 

TOTAL  ACTIVE  DUTY  SERVICE 
DATE  (DDMMMYY) 

7 

PERSONNEL 

TAFMSD 

TOTAL  ACTIVE  MEDICAL  SER¬ 
VICE  DATE  (DDMMMYY) 

7 

PERSONNEL 

TTL: REF: DATE 

TOTAL  AIR  EVACS  IN,  OUT, 
TRANSIENT  BED  DAYS  REFER¬ 
ENCED  DATE  (DDMMYY) 

6 

WARD 

TTL: IN:EVACS 

CUMULATIVE  TOTAL  OF  AIR 
EVAC  PATIENTS  WHO  HAVE 
ENTERED  THE  WARD  SINCE 
TTL: DATE 

3 

WARD 

TTL : OUT : EVACS 

CUMULATIVE  TOTAL  OF  AIR 
EVAC  PATIENTS  WHO  HAVE 
LEFT  THE  WARD  SINCE 
TTL: DATE 

2 

APPOINTMENT 

TYP 

TYPE  OF  APPOINTMENT:  DI¬ 
RECT,  TRANSFER,  PRE-AD¬ 
MISSION,  ETC. 

5 

ADMISSION 
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TYP:CASE 

ACTIVITY  THAT  RESULTED  IN 
THE  ACCIDENT  (EX:  00001  - 
PLY  ACCIDENT) 

50 

PATIENT 

UNIT: ADDR 

MAILING  ADDRESS  OF  AS¬ 
SIGNED  DUTY  SECTION  (OF¬ 
FICE  SYMBOL,  COMMAND, 
BASE,  STATE,  ZIP) 

6 

HISTORY 

UPDATE: REG¬ 
ISTER 

DATE  REGISTRATION  RECORD 
WAS  CHANGED  OR  VERIFIED 
(DDMMYY ) 

3 

ADMINISTRATIVE 

WARD 

WARD  ASSIGNMENT 

3 

ADMINISTRATIVE 

WARD# 

WARD  ID  NUMBER 

3 

ADMISSION 

ROOMS 

SUPERVISOR 

WARD 

WORK: AREA 

ASSIGNED  WORK  LOCATION 
(CLINIC,  WARD,  EMERGENCY, 
ETC.) 

3 

PERSONNEL 

X-RAY :RQS 

X-RAY  REQUESTED  TO  BE 

SENT  TO  CLINIC  PRIOR  TO 
SCHEDULED  APPOINTMENT 
(Y/N) 

1 

APPOINTMENT 

ZIP 

ZIP  CODE  OF:  PATIENT, 
PRIMARY  CONTACT  IN  EMER¬ 
GENCY,  SPONSOR,  ETC.) 

5 

EMERGENCY 

MEDICAL 

INSTITUTION 

REGISTRATION 

SPONSOR 

#AIR:IN 

NUMBER  OF  NEW  AIR  EVAC 
PATIENTS  WHO  HAVE  ENTERED 
THE  WARD  SINCE  LAST  UP¬ 
DATE 

3 

WARD 

# AIR : OUT 

NUMBER  OF  NEW  AIR  EVAC 
PATIENTS  WHO  HAVE  LEFT 
WARD  SINCE  LAST  UPDATE 

3 

WARD 

#AUTH: NURSES 

OFFICIAL  NUMBER  OF  ALLO¬ 
CATED  NURSING  SLOTS 

3 

WARD 

#BEDS 

NUMBER  OF  BEDS  ASSIGNED 
TO  A  WARD 

3 

ROOM 

#EMP 

NUMBER  OF  ASSIGNED  PER¬ 
SONNEL 

3 

SUPERVISOR 

0-11 


^NURSES 

ACTUAL  NUMBER  OF  NURSES 
PRESENT  FOR  A  SHIFT 

3 

WARD 

#RM 

NUMBER  OF  ROOMS 

H 

WARD 

2APSC 

SECONDARY  AIR  FORCE  SPE¬ 
CIALTY  CODE 

5 

PERSONNEL 

3APSC 

TERTIARY  AIR  FORCE  SPE¬ 
CIALTY  CODE 

5 

PERSONNEL 
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Appendix  H 


FUNCTIONAL  DESCRIPTIONS  OF  EACH  RELATION 


1 .  PATIENT 

This  relation  contains  a  list  of  identifying 
information  of  a  patient  for  clinic  use.  Each  patient  is 
uniquely  identified  by  social  security  number  and  dependent 
code.  A  centralized  appointment  center  is  responsible  for 
alterations  to  the  data. 

2 .  APPOINTMENT 

This  relation  contains  information  pertaining  to  when 
an  appointment  for  a  specific  clinic  is  scheduled.  The 
relation  used  social  security  number  and  dependent  code  to 
link  it  to  other  relations  in  the  data  base.  A  centralized 
appointment  center  is  responsible  for  alterations  to  the 
data. 

3 .  TIME_SLOT 

This  relation  contains  schedule  data  each  doctor  has 
for  a  specific  clinic.  The  relation  is  linked  to  other 
relations  through  PROV#.  Each  department  specialty  is 
responsible  for  maintaining  the  data. 

4.  CLINIC 

This  relation  contains  information  that  shows  the  title 
of  the  specific  clinic  and  the  number  of  appointments  it  is 
capable  of  handling  in  a  24  hour  period.  The  relation  is 
accessed  by  the  unique  clinic  number.  Each  clinic  Is 
responsible  for  any  alterations  to  this  relation. 

5.  PROVIDERS 

This  relation  contains  the  social  security  number  for 
each  physician  along  with  his  medical  Identification  number. 
The  Directorate  of  Hospital  Services  (SGH)  would  be 
responsible  for  maintenance  of  the  data. 

6.  PROVIDER_SPECIALTY 

This  relation  contains  data  which  identifies  the 
specialty  of  each  physician  is  qualified  to  perform.  The 
relation  is  linked  to  other  relations  through  the  PROV#. 
SOH  would  be  the  office  responsible  for  maintenance  of  the 
data. 

7.  PROVIDER  CLINIC 

This  relation  contains  data  which  Identifies  the  clinic 
each  physician  is  assigned.  Each  specialty  department  would 
be  responsible  for  maintenance  of  the  data. 
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8.  HOLIDAYS 

The  relation  contains  the  scheduled  dates  the  clinic  is 
closed.  The  clinic's  identification  number  links  it  to  other 
relations.  Each  clinic  is  responsible  for  the  maintenance 
of  the  data. 

9.  REGISTRATION 

This  relation  contains  demographic  data  of  each 
inpatient.  Social  security  number  and  dependent  code  link 
it  to  other  relations.  The  admissions  department  would  be 
responsible  for  maintenance  of  the  data. 


10.  SPONSOR 

This  relation  contains  demographic  information  about  an 
inpatient.  Social  security  number  links  it  to  other 
relations.  The  admissions  department  would  be  responsible 
for  maintenance  of  the  data. 


11.  HISTORY 

This  relation  contains  historical  and  demographic  data 
about  an  inpatient.  Social  security  number  links  it  to 
other  relations.  The  ward  the  patient  is  housed  on  would  be 
responsible  for  maintenance  of  the  data. 

12.  ADMISSION 

This  relation  contains  the  most  current  data  about  an 
inpatient  and  his/her  medical  condition.  In  addition  It 
provides  an  audit  trail  for  cost,  physician  activity  and 
patient  load  on  the  hospital.  Social  security  number  links 
it  to  other  relations.  Admission  clerk  is  responsible  for 
maintenance  of  the  data. 

13.  ADMINISTRATIVE 

This  relation  contains  data  that  Is  used  to  guage  usage 
of  personnel  and  facilities  along  with  monitoring  location 
of  inpatient.  The  ward  the  patient  is  physically  on  is 
responsible  for  maintenance  of  the  data. 

1U.  MEB 

This  relation  contains  data  on  Medical  Evaluation 
Boards.  Social  security  number  and  dependent  code  link  it 
to  other  relations.  Patient  Affairs  (SGR)  would  be  respon¬ 
sible  for  maintenance  of  the  data. 

15.  TRANSFER 

This  relation  contains  data  on  inpatients  that  are 
transported  to  other  medical  facilities  or  into  WPAFB-MC. 
The  primary  purpose  is  to  maintain  sorted  record  of  days 
hospitalized.  The  ward  the  patient  is  assigned  to  would  be 
responsible  for  maintenance  of  the  data. 
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16.  EMERGENCY 

This  relation  contains  data  on  who  to  notify  if  a 
patient  experiences  serious  medical  complications.  The  ward 
the  patient  is  assigned  would  be  responsible  for  maintenance 
of  the  data. 

17.  ABSENT 

This  relation  contains  data  cn  patients  that  are  not 
physically  in  the  hospital.  They  may  be  on  pass  or  located 
in  a  local  hospital.  The  ward  the  patient  is  assigned  would 
be  responsible  for  maintenance  of  the  data. 

18.  CASUALTY 

This  relation  contains  data  on  inpatient  admissions 
for  problems  not  related  to  viral  or  bacterial  pathogens. 
Social  security  number  and  dependent  code  link  it  to  other 
relations.  Admissions  office  would  be  responsible  for 
maintenance  of  the  data. 

19.  DISPOSITION 

This  relation  contains  information  on  inpatient 
discharges.  Social  security  number  and  dependent  code  link 
it  to  other  relations.  The  ward  the  patient  was  assigned 
would  be  responsible  for  maintenance  of  the  data. 

20.  WARD 

This  relation  contains  data  on  personnel  and  patients 
assigned  to  a  specific  ward.  It  also  contains  data  on 
equipment  located  in  the  ward.  Each  ward  would  be  re¬ 
sponsible  for  maintenance  of  the  data. 

21.  BED  STATUS 

ThTs  relation  contains  data  on  availability  of  beds. 
Each  ward  would  be  responsible  for  maintenance  of  the  data. 

22.  ROOMS 

This  relation  contains  data  on  the  equipment  each  room 
has  along  with  the  location  of  the  room.  Plant  Management 
would  be  responsible  for  maintenance  of  the  data. 

23.  SUPERVISOR 

This  relation  contains  data  used  to  track  supervisory 
personnel.  SGH  would  be  responsible  for  maintenance  of  the 
data. 

24.  PERSONNEL 

This  relation  contains  demographic  and  credential  data 
of  each  person  assigned  to  the  hospital.  Administrative 
Office  would  be  responsible  for  maintenance  of  the  data. 

25.  MEDICAL  INSTITUTION 

This  “relation  contains  location  data  of  medical 
facilities  that  WPAFB-MC  has  patients  transferred  to  or  in 
from. 
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Appendix  I 


RELATIONS 

(KEYS  FOR  EACH  RELATION  ARE  DENOTED  BY  ”*"s) 


1.  PATIENT 

•SSAN,  *DEP:CODE,  NAME,  BENErTYP,  SEX,  HM: PH,  DTY : PH ,  DOB, 
FL:  STAT,  ADDR,  SPON,  UNIT-ADDR 


2.  APPOINTMENT 

•SSAN,  *DEP:CODE,  CLINIC# ,  TYP,  PROV#,  DATE,  ST-TM,  STP-TM, 
PROB,  REC-REQ,  XRAY-REQ,  ARVL-  TIME,  PRIOR 

3.  TIME  SLOT 

•DATE,  «ST-TIM,  *PROV# 

CLINIC 

•CLINIC#,  MAX-APT,  TITLE 

5.  PROVIDERS 
•SSAN,  *PROV# 

6.  PROVIDERS  SPECIALTY 
•PROV#,  SPEC-CODE 

7.  PROVIDER  CLINIC 
•PROV#,  •CLINIC# 

8.  HOLIDAYS 
•DATE-CLSD,  *CLINIC# 
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9.  REGISTRATION 


•SSAN,  *DEP:CODE,  NAME,  A DDR,  CITY,  STATE,  ZIP,  HM : PH , 
DAY: PH,  PATIENT: CAT,  SEX,  MARITAL: STATUS,  RACE,  RELIGION, 
PRIM: CARE  PROVIDER,  PRIME:MTF,  ID:CD:EXP,  PLY:SVC:CODE, 
EXPIR : TRM : SRVC ,  LNGTH:SVC,  REGISTER: NO,  AERO:RTNG, 
MEB: STATUS 


10.  SPONSOR 

•SSAN,  NAME,  RANK,  SERVICE,  COMND: INTRST,  ADDR,  CITY,  STATE, 
ZIP 


11.  HISTORY 

•SSAN,  *DEP:CODE,  LST: INPAT: STATUS ,  CUR:REGIST:NO,  UP- 
DATE:REGIST,  LST:  INPAT:  DISPO,  PREV:REGIST:NO,  LST.'OUT- 
PAT: CLINIC,  DATE,  DATE: INACT: STATUS 


12.  ADMISSION 

•SSAN,  *DEP: CODE,  DATE,  TIME,  SOURCE: ADM,  ADMIT: PHY,  CLERK, 
TYP.-CASE,  ADMIT:  DIAG,  MED:HLD,  MEAL:  CD,  ORG :  AUTH :  ADM , 
LNGTH :  SVC ,  MEB  .-STATUS,  CASUALTY,  ABSENT:  STAT,  DATE:  CNX 


13.  ADMINISTRATIVE 

•SSAN,  *DEP:CODE,  ADMIT: STAT,  WARD,  PROJ:DISPO,  ATND: PHY , 
DATE: AS I GN,  NEW: MOD,  CLINIC: SVC,  DATE: SVC 


lit .  MEB 

•SSAN,  *DEP:CODE,  MEB:  STATUS,  DATE-.CONFMD,  DATE:  I  DENT, 
DATE : RESOLV 


15.  TRANSFER 

•SSAN,  *DEP:CODE,  INIT: ADMIT,  PREV:BED:DYS,  PREV : QTR : DYS , 
PREV : COOP : DYS ,  ADMIT: DATE,  PREV:SICK:DYS,  PREV :CONV: DYS, 
PREV :OTHR: DYS,  PREV: SUP: DYS 


16.  EMERGENCY 

•SSAN,  *DEP:CODE,  NOTIFY: NAME,  RELATION,  ADDR,  CITY,  STATE, 
ZIP,  PHONE,  LEGAL :NXT: KIN,  RELATION,  ADDR,  CITY,  STATE,  ZIP, 
PHONE 
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17.  ABSENT 


•SSAN,  BDEP: CODE,  EFP: DATE: TIME,  ABSENT :STAT, 

DATE :RTRN: TIME,  CIV:MTF,  PHY,  PHONE 


18.  CASUALTY 

•SSAN,  *DEP:CODE,  DIAGNOSIS,  DATE: KIN :NTFY,  DATE, 
PROB:RECVR,  DATE : CHG ,  DATE : RMVD 


19.  DISPOSITION 

•SSAN,  *DEP:CODE,  DATE-.DISPO,  TIME,  ADMIT  :STAT,  CLERK, 
TRANSFR:MTF,DISPO# ,  PHY:  DISCHG,  PHY : AUTH 
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20.  WARD 

•WARD#,  #AIR:IN,  #AIR:OUT,  CUR:AIRIN,  CUR:AIROUT, 
TTL: REF: DATE,  TTL: IN:EVACS ,  TTL:OUT:EVACS,  AIR:EVACS, 
BED:DYS,  #BEDS,  #RM,  SUPERVISOR,  #AUTH: NURSES,  #NURSES 


21.  BED  STATUS 

•BED#,  AVAIL: BED,  RM# ,  BLCK:BED,  OCCUPY: BED,  PREADMITS 


22.  ROOMS 

•RM#,  LOCK#,  KEY#,  #BEDS,  PHONE,  INSP: DATE,  WARD# 


23.  SUPERVISOR 

•SSAN,  LV,  KEY#,  WARD#,  #EMP 


2H.  PERSONNEL 

•SSAN,  NAME,  RANK,  DOR,  TAFSCD,  TAFMSD,  DOB,  DAS,  ADSCD, 
PAFC ,  DAFSC ,  2AFSC,  3AFSC,  OFC:SYMB,  DTY : PH ,  DTY: TITLE, 
HM : PH ,  GAIN: DATE,  LOSS: DATE,  POS# ,  SUPERVISOR : SSAN, 
CPR : TRNG : CODE ,  C PR: DATE,  SEX,  WORK: AREA 


25.  MEDICAL  INSTITUTION 

•MTF,  ADDR,  CITY,  STATE,  ZIP,  PHONE,  SERVC 
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Appendix  J 


Relation: 

Domain: 

Attribute: 

Tuple: 

Primary  Key: 

3NF: 


Glossary 


given  a  collection  of  sets  D-l,  D -2  ...  D-n;  R 
is  a  relation  of  these  sets  if  it  is  the  N 
tuple  such  that  tuple  element  d-l  comes  from  D- 
1,  d-2  comes  from  D-2  ...  d-n  from  D-n. 

in  the  data  base  context  is  the  defined  set  of 
characteristics  from  which  an  attribute  of  a 
relation  may  be  drawn. 

a  single  tuple  element  drawn  from  a  designated 
domain;  column  In  a  relation. 

a  collection  of  attributes;  rows  in  a  relation. 

an  attribute  or  combination  of  attributes  which 
yeild  a  unique  identification  property  to  a 
tuple. 

transitive  dependencies  are  eliminated 
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